Workflow series #1 - Building a buy now, pay later (BNPL) payment flow that scales

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 Numeral 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 Numeral 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 executed 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 Numeral 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, Numeral updates the reconciliation status of the payment order and creates a reconciliation between the payment and associated transaction. If webhooks are set up, Numeral also notifies the BNPL’s systems of the reconciliation.

Getting notified of rejections and returns

Unfortunately, the average failure rate of a direct debit can be anywhere between 2.6% and 3%. Payment operations teams, therefore, have to expect and manage rejections as quickly as possible. In a similar vein, a direct debit can be refunded for up to 13 months by a customer (in the case of a core SEPA direct debit) after being processed.

Direct debit R-Operations (rejects, refunds, returns…) trigger in Numeral an update in real-time of the payment order status as well as the creation of a proper return. As a consequence, the direct debit R-Operation results in a debit entry in the BNPL provider account statement. Again, the Numeral reconciliation engine automatically reconciles the SEPA direct debit return with the corresponding debit transaction, for all categories of R-Operations. Webhook notifications are sent to the BNPL provider’s systems for action at each step.

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 Numeral.

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 Numeral 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 Numeral, 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 Numeral automatic reconciliation engine will create a reconciliation between this transaction and the expected payment, updating it to reconciled status. Numeral 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 Numeral 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.