Workflow series #1
Building a “buy now, pay later” (BNPL) payment flow that scales
6 February 2023
Credit has been part of human society for over 5,000 years in various forms. And one of its most recent developments is buy now, pay later (or BNPL), embedding credit at the point of purchase in a seamless user experience. Fast forward to today, the BNPL industry is expected to be worth US$ 141.8 billion in 2021 and is expected to grow at a compound annual growth rate of 33% over 2021-2026, highlighting how ubiquitous payment by instalments is becoming.
While BNPL providers introduced a simplified buyer experience compared to incumbents, their payment operations are highly complex due to the number of transactions involved. Instead of one payment flow from the buyer to the merchant, the BNPL model has two main payment flows:
- Paying out merchants: Merchants are usually paid in the next 24-48 hours following the purchase, ensuring the BNPL offering doesn’t impact the merchant’s working capital. Every day, BNPL providers pay thousands of providers for the purchase of the previous day. This is usually done through bank transfers.
- Collecting instalments from buyers: BNPL instalments can range from pay in 3 to pay in 12 for certain goods and industries. And for each planned instalment in the credit plan, the BNPL provider has to collect funds from the buyer through credit card or direct debit. With 4+ payments to be made per individual purchase for millions of buyers, even a small percentage of errors and overdue instalments creates an exponential complexity. After a certain threshold, manual operations start to break down and the BNPL provider needs a payment operations system to automate reconciliations and cut the time needed to manage the long tail of errors.
In this article, we take a step by step approach at implementing a simplified BNPL payment flow with the Mambu Payments API, inspired by customers such as Alma. Let’s build.
Paying out merchants
Creating the merchant account
Once a merchant finishes their onboarding process, the BNPL provider saves their bank account details by creating a counterparty and counterparty account in Numeral.
POST https://api.numeral.io/v1/counterparties
POST https://sandbox.numeral.io/v1/counterparty_accounts
Creating a payment order
Now onto the merchant payout. At the end of every day for each merchant counterparty with a positive balance, the BNPL provider creates a payment order with the merchant as the counterparty to settle the amount due. This amount is equal to the amount collected from the buyers minus the BPNL provider’s fees.
POST https://api.numeral.io/v1/payment_orders
Approving and sending payment orders to the bank
Before payment orders are sent to the bank, finance team members or select executives can review and approve them. This can be done at the individual payment order level and / or the payment file level, using the API and the dashboard.
POST https://api.numeral.io/v1/payment_orders/{id}/approve
POST https://api.numeral.io/v1/files/{id}/approve
Monitoring payment orders
As payment orders are processed by Mambu Payments and by the BNPL provider’s partner banks, their status update, generating unique events in Numeral. Events can be queried using the API, received through webhooks, or accessed on the dashboard. They can be used by the BNPL provider to update their own system and records, such as merchant and buyer internal account balances.
Additionally, finance and operations teams also have access to the Numeral dashboard and can filter by the payment batch number or the payment date to check the status of all payouts sent. They can also filter by error status to manage exceptions when needed, saving time on error management.
Collecting instalments from buyers
Collecting instalments is the most challenging operational part of a payment operations team at a BNPL provider.
There are two main ways for BNPL providers to collect instalments:
- Through debit / credit cards, initiating the payment from a card previously captured
- Through direct debits, initiating the payment from a mandate previously signed Ultimately, payment methods used to collect instalments depend on customer preferences and vary by countries in Europe. In this section, we will assume that our BNPL provider operates in Germany, where direct debit is used for both instalments and late payment collections.
Creating a payment order
For every instalment due, the BNPL provider creates a payment order to initiate a direct debit. The payment order includes the instalment details as well the associated direct debit mandate details.
POST https://api.numeral.io/v1/payment_orders
Just like any payment order, it can be reviewed and approved, at the payment order level or payment file level, before it is sent to the bank.
Reconciling the payment order with the corresponding account credit transaction
The direct debit operation’s status is set to execute after reception of a payment status report from the bank. At this stage, BNPL can expect to get a credit transaction booked in the next end-of-day account statement file.
The Mambu Payments reconciliation engine automatically reconciles this credit transaction with the direct debit operation based on a combination of data around the payment itself, its counterparty and various technical IDs.
Consequently, Mambu Payments updates the reconciliation status of the payment order and creates a reconciliation between the payment and associated transaction. If webhooks are set up, Mambu Payments also notifies the BNPL’s systems of the reconciliation.
Getting notified of rejections and returns
Collecting overdue instalments
As with any credit business model and provider, loans or instalments not repaid on time happen. On a daily basis, recovery teams (or automated crons) would query for all the failed direct debits and communicate with the customer before initiating another direct debit, until the customer settles all outstanding instalments.
However, failed retries can be costly for the BNPL provider. To reduce recovery costs, the payment operations team may request the customer to pay by bank transfer instead of retrying multiple times with direct debit. Let’s deep dive into this scenario.
Creating and assigning a virtual account
The recovery team wants to be able to share a unique IBAN with the customer to allow for funds received to be reconciled more easily. To do so, it would create a virtual account (using a virtual IBAN provided by a banking partner) and associate it with the customer counterparty in Mambu Payments.
POST https://api.numeral.io/v1/virtual_accounts
POST https://api.numeral.io/v1/virtual_accounts/{virtual_account_id}/counterparties/{counterparty_id}/assign
Creating an expected payment
The recovery team then creates an expected payment in Mambu Payments corresponding to the amount expected to be paid by the counterparty, specifying when this amount is due. An expected payment is a payment that is not initiated through Mambu Payments, but that you nonetheless want to track and reconcile with a transaction. The expected payment is linked to the virtual account created above.
POST https://api.numeral.io/v1/expected_payments
Reconciling and monitoring expected payments
Upon receipt of a transaction on the bank account using the virtual account (the repayment from the customer), the Mambu Payments automatic reconciliation engine will create a reconciliation between this transaction and the expected payment, updating it to reconciled status. Mambu Payments will also send a real - time notification through webhooks.
The list of all reconciliations is viewed by searching through the reconciliations objects. Partially reconciled payments due to account mismatches can then be manually handled on a case per case basis.
GET https://api.numeral.io/v1/reconciliations
That’s it! Our BNPL payment workflow is now ready to go live.
Managing payment inquiries
While all those payment workflows take place, multiple teams need to be able to access the latest status of payments for their own objectives. The Mambu Payments dashboard makes it easy to create transparency on a company payment flows.
Finance teams can easily access details about payment errors and returns to take actions. For payments partially reconciled, finance teams can also manually adjust reconciliation status to close the books faster.
Customer service teams with a read-only access to the dashboard can filter by customer or payment and answer customer queries faster and without dependencies on other teams.
© Mambu 2026