8 octobre 2026

Today's highlights:

1. Refunds from Monetization: the community refunds a buyer from the Sales tab, without waiting on the Memberfy team, and chooses whether they keep access.
2. Payouts that go to the bank right away: a payout goes to the bank the moment it's requested, with no manual approval, and the account receives exactly the amount requested.
3. The whole sale, with its timeline: the Sales tab shows one line per sale with its status, and each sale opens into a detail with everything that happened to it, in order.
4. Refunding part of a sale: on card and PIX, the community returns just part of the amount, as many times as needed, up to the total.
5. The Store in three sections: the storefront shows products, plans and add-ons, a plan can be link only, and a product opens into details with the Buy button.

Then come the improvements and the fixes. At the end, separately, what matters to developers.

Today's changes are for communities that sell in reais (communities in Brazil). Selling and paying out in dollars is still on its way.

#Refunds from Monetization

What it is. The new Sales tab in Monetization lists every purchase in the community (one-time products, plans and add-ons) with the buyer, the amount, the net, the payment method and the refund status. The Refund button lives there. In the dialog, you say whether the buyer keeps or loses access, and Memberfy returns the money.

Why it matters. Before, returning a sale meant writing to the Memberfy team and waiting. Now the owner, the admin and finance refund right away, and decide on access at the same time: keep it for a discount agreed after the purchase, or remove it when someone gives up.

• Keep or revoke access. On a one-time product or add-on, revoking removes access to the product. On a subscription, revoking cancels the subscription right away, and the dialog warns you before you confirm. Even with access kept, the purchase shows as Refunded, with the amount and the date.
• On card and PIX, Memberfy returns the money through the same payment method. The platform fee goes back too, in proportion to the amount returned, and the community only returns the part it received. You can return the whole amount or just part of it (see Refunding part of a sale).
• A refund that waits for balance. If the community's receiving account doesn't have the balance for its part yet, the refund stays Pending: waiting for balance and goes out on its own when balance comes in, in order of arrival. The access choice applies right away, and the amount is reserved: it isn't available for payout.
• Boleto returned directly. A paid boleto isn't returned by the payment provider. The community returns the money directly to the buyer, by PIX or bank transfer, and records the return in the same dialog (it can be just part of it). Nothing leaves the community's balance and the platform fee doesn't come back.
• The buyer gets an e-mail with the amount and whether access continues; the community gets a refund notice.

Where it is. Monetization › Sales, on the purchase's row. For a subscription, also under Members › Subscriptions › View details › Charge history, next to each paid charge.

How to start.

1. In Monetization › Sales, find the purchase by the buyer's name or e-mail and click Refund.
2. Under What about access?, choose Keep access or Revoke access and, if you like, write the reason.
3. Click Refund R$ …. On a boleto, check I already returned it to the buyer, fill in the amount and the date, and click Record return of R$ ….

Example. Maria bought the R$ 297 course by PIX and you agreed on a discount after the purchase. You refund it keeping access: the R$ 297.00 goes back to her by PIX, she stays in the course, and the sale shows as Refunded in the Sales tab.

See Sales and Refunds and disputes.

Through the assistant. The same works in a conversation with Claude or ChatGPT: "Refund [email protected]'s course purchase. She keeps access." The assistant finds the purchase, asks whether access continues and only refunds after your yes to a summary. There's also the ready-made recipe Refund a buyer. See Recipes.

#Payouts that go to the bank right away

What it is. When an owner or admin confirms a payout, Memberfy sends the transfer to the bank at that moment, with no manual approval from anyone. The credit is expected the next business day.

Why it matters. Before, the request stayed Pending until the Memberfy team made the transfer by hand. Now the money leaves when you ask, and the history shows the real state: Processing until the bank confirms, Completed when the credit lands, or Failed, with the reason.

• The account receives exactly the amount requested. The payout fee comes out of the balance, on top of the amount.
• The maximum comes already worked out. The dialog shows what's available, the maximum (already without the fee and without what's reserved for refunds) and the minimum. The Withdraw the maximum button fills in the amount.
• If the bank refuses it, the payout ends up Failed, the amount and the fee go back to the balance, and the history gives the reason. Once the account is fixed, just request it again.

Where it is. Monetization › Dashboard › Request Payout. The history is under Monetization › Payments › Payout history.

How to start.

1. In Monetization › Dashboard, click Request Payout.
2. Type the amount under How much you want to receive or click Withdraw the maximum, and check the fee and what leaves the balance.
3. Click Confirm payout.

Example. With R$ 1,000.00 available, the maximum is R$ 996.33: the account receives the full R$ 996.33 the next business day, and R$ 1,000.00 leaves the balance.

See Payouts.

#The whole sale, with its timeline

What it is. The Sales tab now shows one line per sale, with the buyer, the product, the Status, the amount and the net, the payment and the date. Each sale opens into a detail: the summary, the Refund button and the timeline, with the payment, the balance release, the reserve, each step of a refund and the e-mails the buyer received.

Why it matters. Before, to understand what had happened to a purchase you had to piece together the list, the refund history and the statement. Now the answer to "what happened to Maria's purchase?" is on one screen.

• The status, in a word. Paid, Processing, Waiting for balance, Refunded, Partially refunded, Returned directly, Disputed, Awaiting payment, Failed… Hover to see a refund's amount, date and access.
• The Status filter uses the same names as the column and replaces the old filters.
• The ⋮ menu on each line leads to View details and, while there is something left to return, to Refund. Clicking the line also opens the detail.

Where it is. Monetization › Sales.

How to start.

1. In Monetization › Sales, search for the buyer by name or e-mail.
2. Click the sale (or ⋮ › View details).
3. Read the timeline from top to bottom; a future date is when something will still be released.

Example. Maria asks when the money from her purchase reaches the community. In the detail, the timeline shows the PIX payment on 10/8, the release for payout on 11/7 and the 4% reserve coming back on 12/7, with the scheduled badge on what hasn't happened yet.

See Sales.

#Refunding part of a sale

What it is. On card and PIX, a refund can be part of the amount: from R$ 0.01 up to what can still be refunded. A purchase accepts several partial refunds, up to the total. And in an order with a plan and add-ons paid together, each purchase is refunded on its own.

Why it matters. Before, on card and PIX only the whole remainder of the charge could be refunded, and a purchase that shared its charge with others wasn't refunded through Memberfy. Now a discount agreed after the purchase, or returning just one add-on, goes through the Sales tab itself.

• The platform fee goes back in the same proportion as the amount returned, and only the community's share leaves the balance.
• A partial refund usually stays Processing for a few minutes while the reversal is confirmed; the status updates on its own.

Where it is. Monetization › Sales, under Refund, in the amount field.

How to start.

1. In Monetization › Sales, open the sale and click Refund.
2. Change the amount to what you want to return and choose whether access continues.
3. Confirm. The Refund button stays on the sale for what's left.

Example. From a R$ 197.00 PIX sale, the community returns only R$ 50.00, a discount agreed with the buyer. Access continues, and the sale shows as Partially refunded.

See Refunds and disputes.

#The Store in three sections

What it is. The Store now sells by plans. The storefront is organized into up to three sections, in this order: Products (the one-off ones), Plans (each plan once, with the "from" lowest price) and Add-ons. An empty section doesn't show. Clicking a product opens its details, with Buy and Copy link, and plans gained the Public or Link only visibility.

Why it matters. Before, a billing option (Monthly, Annual) showed in the Store as if it were a standalone product, and an add-on could be bought alone, outside the plan. Now the person picks the plan, then the option, and an add-on is only bought through its plan. And you can have a plan that shows up nowhere and only opens through a link: for an invitation, a partner, a cohort.

• Each add-on shows the viewer's state: Add (summed to your subscription, at the prorated amount), You already have it, Available on the X plan with Upgrade, or Subscribe to the X plan to add it.
• The storefront picker (Choose products) also has the three groups: picking a plan picks all of its options, and a billing option is never picked on its own.
• Link only hides, it doesn't protect. The plan disappears from the pricing page, the Store and the picker, but whoever has the address (/pricing/<address>) buys normally.
• Every billing option belongs to a plan. An option without a plan shows in Monetization › Options with the No plan badge, and isn't for sale. Deleting a plan that still has options is refused, with their names.
• Stock with reservation. On a product with Control Stock?, the unit is reserved on the order. Once they run out, Sold out shows in the Store, in the direct-link catalog and in the purchase window, in place of the Buy button, and checkout refuses. A boleto holds the unit until it's due; the unit comes back if the payment fails, if the PIX or the boleto expires, or if a refund removes access. Partial refunds and chargebacks don't return it. In Monetization › Products, admins see "N available" or Sold out. See Products.

Where it is. The Store is the space you created; the plan's visibility is in Monetization › Plans, in the Plan visibility field.

How to start.

1. In Monetization › Plans, edit a plan and choose Link only under Plan visibility, if you want to hide it. Copy the Plan link.
2. Open the Store and click Choose products. With Chosen products, check what the store sells, in the three groups.
3. Open the Store as a member: click a product to see its details, then Buy.

Example. A school sells the one-off course Excel from Scratch, the Student plan (Monthly and Annual) and the Group mentoring add-on. The Store shows the course under Products, the plan Student, from R$ 49 under Plans and the mentoring under Add-ons, which, for someone who doesn't subscribe, says Subscribe to the Student plan to add it. The March cohort plan, just for that cohort, is Link only and goes out by email.

See Store, Plans and Add-ons.

#Other news

• Creating a space asks only what changes the space. Before, some modules asked for options that changed nothing (Feed post types, Gallery layout, Ranking options, course sequence). Now each module asks only what counts: Link asks for the address, Certificates asks Who issues, Store asks for the storefront and Call for papers asks how many calls. If a setting isn't saved, the space already exists and the window offers Try again, without creating a second space. See Spaces.

• Who can open a call, on screen. In a call space with Several calls, creating and editing the space now show Who can open a call: Staff (the default), Admins or Members. Before, this rule could only be changed through the assistant. See Call for papers.

• The storefront when creating a Store. Step 3 of creating a Store, Storefront, chooses what it shows: All active products (the default) or Chosen products. Before, the store started out showing everything, and the choice came later. See Store.

• Counters in the Help Center. The MCP and API home pages show how many tools and recipes the assistant has and how many endpoints the API has, with the total in each of the same 8 product areas and a link to each page. The numbers come from Memberfy itself, in production, every time the Help Center is published.

• Sale times in the community's time zone, and View subscription. The sales list, the detail and the timeline show times in the community's time zone (that of the business information's country), with a note saying which one, instead of the viewer's time zone. A refund waiting for balance shows its Last attempt. And on a plan sale, the View subscription button opens the subscription in Members › Subscriptions. See Sales.

• The community's time zone in subscriptions, the statement and payouts too. Subscription, statement and payout dates and times follow the community's time zone, not the viewer's. See Balance and statement and Payouts.

• The assistant's tools on the website. The MCP page on the Memberfy website shows the 207 tools in the same 8 areas as the Help Center, and the 4% reserve for 60 days on every sale.

• Images on products and plans, through the assistant. create_product and update_product take the product's banner (16:9) and featured image (1:1), by link or file; create_plan and update_plan send the images to every option of the plan (a plan has no image of its own). An invalid image changes nothing: the assistant stops and explains. Details in Tools · Sales and plans.

#Improvements

• Sales that switch on and off right away. When the payout registration changes status, the community's sales switch on or off at the same moment. Before, the change could take up to 1 hour to apply. See Business information and payout account.

• Clearer declined-payment messages. The messages the buyer sees when a payment is declined are clearer. See Checkout.

• A 30-day release period, for every method. Before, PIX was available on the day of payment, boleto 1 day after clearing and card after 30 days. Now every sale becomes available for payout 30 days after payment, with any method, and each sale shows the date under Releases on. On a card sale in installments, each installment is released on its own date. See Balance and statement.

• A 4% reserve for 60 days, with every payment method. Before, only card had a reserve, held for 30 days. Now 4% of the gross amount of each sale, by card, PIX or boleto, is held for 60 days to cover disputes and goes back to available on its date. See Balance and statement.

• The balance shows where each amount comes from. The Dashboard separates Pending (sales before their release date, with the next release), Retained (the dispute reserve) and Available for Payout. When a refund or a dispute takes available below zero, the amount owed appears, and it comes out of the next sales released. Before, a negative balance showed as zero.

• A R$ 10.00 minimum payout. A payout below that is refused, and the dialog shows the minimum before you type the amount. See Payouts.

• A R$ 3.67 payout fee. Memberfy's fee per payout is still R$ 3.67, charged on top of the amount requested: the account receives the full amount. The dialog shows the fee and the total that leaves the balance before you confirm. See Platform fee.

• No advances and no automatic transfers. Money only leaves when an owner or admin requests a payout. The Automatic Transfers section is gone from Settings › Payout Settings, and the Transfer Interval line is gone from Monetization › Payments. See Business information and payout account.

• Clearer payout registration texts. The messages and e-mails about the payout registration (the review, the activation, sales switched off and refused details) are more direct and no longer name the payment provider. In the sales-switched-off e-mail, the field is now called Payout status. See Business information and payout account.

• New security controls. We applied new security controls to Memberfy. Nothing changes in how you use it: everyone keeps seeing and doing the same as before.

• The plan window in three columns. On wide screens, creating or editing a plan shows three columns side by side: the plan's identity, the benefits and the billing options, with the add-ons below across the full width. On a phone it stays one column. See Plans.

#Fixes

• An add-on bought alone. Before, anyone who had the plan could buy an add-on as a loose subscription, with its own cycle and billing date. Now checkout refuses it for everyone, with a message that shows the way: together with the plan or summed to the current subscription. See Add-ons.
• The total balance. Before, the Total balance on the Dashboard could add up the gross and the net of the same sale and show more than the community had. Now it adds up pending, retained and available, and matches the statement.
• Card payments. A change yesterday left cards unavailable at checkout for every community; we caught it and they were working again the same day.

#For developers

This part is for those who integrate Memberfy through code. To use what's above, none of this is needed.

#API

• Sales and refunds. Three new routes, for the X-CommunityId community, for owner, admin and finance: GET /api/manage/purchases (the sales, with the status, productId, paymentMethod, refunded, from, to and search filters), GET /api/manage/purchases/{purchaseId} (one sale, with all its refunds) and POST /api/manage/purchases/{purchaseId}/refunds (refunds it, with access KEEP or REVOKE, a required idempotencyKey and, on boleto, settledOutside). Each sale has refundedAmount, refundableAmount, refundMethod and refundBlockedReason. See Sales and Responses and errors.
• New balance. GET /api/payouts/balance now returns pending (before, always zero), owed, withdrawableBalance, maxPayoutAmount, minPayoutAmount, pendingRefunds and balances[], one line per currency, with ?currency= to choose the currency of the payout calculation. available can be negative. Statement entries have availableAt, one per installment on a card sale in installments, and accept the currency filter.
• Status and timeline. GET /api/manage/purchases accepts the situation filter (one or more) and each sale has situation; GET /api/manage/purchases/{purchaseId} has the timeline, with each event already translated by Accept-Language.
• Store in three groups. GET /api/storefront/spaces/{id}/products returns products, plans (each plan once, with fromPrice) and addOns (with availability owned | add | upgrade | subscribe), plus notices for whoever manages it. PUT gains planIds and refuses a lone billing option in productIds.
• Plan and option always together. POST/PUT /api/products refuse a billing option without a plan (400 subscriptionGroupIds); a PUT /api/subscription-groups/{id} that would leave an option without a plan answers 400 productIds with the names; DELETE with live options refuses and names them. Plans gain visibility (public | link_only), the public list hides link_only (except the viewer's own plan) and GET /api/checkout/subscription-groups/{slug} opens the plan by its address. POST /api/checkout and /checkout/calculate-price refuse an add-on as the main product (400 productId) and an option outside every plan.
• Partial refunds. POST /api/manage/purchases/{purchaseId}/refunds accepts amount (default: the remainder) on card, PIX and boleto, and refunds one purchase on its own in an order with several.
• Payouts. POST /api/payouts answers 201 with the payout in the state it ended up in (PROCESSING or FAILED, with failureCode and failureMessage) and refuses with 400 an amount below the minimum or above the maximum. See Payouts.

#MCP: technical details

• Three new Finance tools: 207 in total. list_purchases and get_purchase (read-only) and refund_purchase (kind: money, asks to confirm; on boleto, settled_outside records the money returned directly). A purchase that can't be refunded through Memberfy yet is refused before the summary, with the reason in refund_blocked. New prompt Refund a buyer (refund_buyer): 10 prompts in all. By role: owner and admin, 207; finance, 103. See Tools · Finance.
• Status, timeline and partial refunds. list_purchases accepts situation and returns situation_label; get_purchase has the timeline; refund_purchase accepts amount to return just part of it on card and PIX.
• Images on products and plans. create_product and update_product accept image_url/image_base64 (+ image_type) and featured_image_url/featured_image_base64 (+ featured_image_type), sent through POST /api/upload/product/{id}/banner and /featured; update_product gains remove_banner and remove_featured_image. In create_plan the top-level images go to every option (each option can bring its own); in update_plan, to every option of the plan. On failure: the single-item tools check the image before changing anything (create_product undoes the product if the upload fails after creating); create_plan never rolls back for an image and returns the reason in warnings; update_plan checks first and reports a refused upload for one option in warnings. The audit log now keeps only the size of *_base64 arguments. See Tools · Sales and plans.
• get_balance returns one line per currency, with pending and its release dates, retained with its return date, owed, the withdrawable amount, the fee, the maximum, the minimum and pending_refunds. list_ledger_entries has each entry's releases on date and accepts currency. request_payout refuses on the first call an amount below the minimum or above the maximum, and the result shows the payout's real state. community_overview gained money_by_currency.
• Bulk editing and a Store with plans. update_products and update_plans (up to 20 items; the price asks for confirmation, images go by link or file) are two new tools in Sales and plans: 209 in total, 27 in Sales and plans. create_product accepts short_description. update_storefront accepts plan_ids (whole plans; a billing option is still refused in product_ids), create_plan and update_plan accept visibility (public or link_only) and list_storefront_products returns the three groups, with the add-on's state for whoever asks and the suggested next step. See Tools · Sales and plans.
• Stock in the MCP. create_product, update_product and update_products accept has_stock and stock_quantity (what's available right now; 0 is sold out); list_products returns availability and sold_out, and the Store (get_storefront, list_storefront_products) returns sold_out, without the count. A sold-out add-on gets no purchase next step.

#API: stock

• POST /api/checkout for a one-off product with stock takes the unit on the order; with no unit left, it answers 409 Sold out (param: productId), and an open PIX or boleto for the same product answers 409 with the open payment in data.openPayment. hasStock without stockQuantity and hasStock on a subscription answer 400. GET /api/checkout/products returns soldOut. The management lists of plans and products (GET /api/subscription-groups, GET /api/products) belong to the owner, the admin and finance; other roles read only what is public. See Responses and errors.