Buy Now Pay Later can improve checkout conversion and make higher-value purchases easier to complete. It can also introduce a second operating system for refunds, disputes, settlement, customer communication and reporting.
That is where many implementations fail.
The checkout button works. Customers are approved. Orders are placed. The problems appear later, when a partial refund does not reconcile, a customer is still being charged after returning an item, a dispute moves between the merchant and finance provider, or settlement terms tighten during a high-refund period.
These are not arguments against BNPL. They are reasons to structure it as a financial and operational workflow rather than a cosmetic payment option.
Vellis BNPL solutions help eligible merchants assess and implement BNPL through an authorized-provider model. Vellis manages the client relationship and setup end to end while working with relevant underlying acquiring, banking and payment partners. You work with Vellis.
A strong implementation defines ownership before launch: who processes each refund, who carries each dispute, when funds settle, what data enters the finance system and who escalates problems when the standard flow breaks.
The Operational Risks BNPL Introduces
BNPL creates a split operating model.
The merchant controls the product, order, fulfilment, cancellation policy and customer service. The BNPL provider controls the credit decision, repayment schedule and part of the payment ledger. The customer experiences both as one purchase.
Risk appears whenever the two systems do not share the same status.
A merchant may mark an order as cancelled while the BNPL plan remains active. A warehouse may accept a return before the refund instruction reaches the provider. A customer may contact the merchant about a repayment issue that only the provider can resolve. Finance may receive a net settlement file that does not clearly identify the order, fee, refund and adjustment behind each amount.
The main pressure points are full and partial refunds, order edits after authorization, split shipments, delayed fulfilment, cancellations after capture, duplicate status notifications, reconciliation and customer-service handoffs.
Before launch, map the complete order lifecycle from approval through final settlement. Include failed approvals, cancellation, full return, partial return, replacement and dispute. The integration is not complete until each outcome has a defined system action and owner.
Refund Complexity and Reconciliation
Refunds are usually the first place where BNPL creates more work than expected.
With a card refund, the merchant sends an instruction against the original transaction. BNPL adds another step because the provider must adjust the customer’s instalment plan. Depending on timing, it may cancel future instalments, return amounts already collected or reduce the remaining balance.
The merchant needs to understand what the customer sees at every stage.
A refund may be approved internally but not yet transmitted. It may be processing with the provider. A partial refund may reduce future instalments rather than produce an immediate cash return. If support agents cannot explain the status, the customer assumes the merchant is withholding money.
Reconciliation also becomes harder when settlement is netted. One payout may combine new sales, fees, refunds, reserve movements, dispute adjustments and corrections. Without reliable identifiers, finance teams must investigate line by line.
The control framework should answer:
- Does the refund start automatically from the commerce platform?
- Can the system process partial refunds accurately?
- What happens when the refund exceeds the unsettled merchant balance?
- Are original merchant fees returned or retained?
- Which report connects the customer refund, BNPL transaction, order and bank settlement?
Test real scenarios, not only a successful full refund in a sandbox. A customer may return one item from a larger order, receive a shipping-only refund or cancel after authorization but before fulfilment.
Merchants should also define a refund service level: when the refund is approved, when the provider instruction is sent, when the customer is informed and when an unresolved case is escalated.
Chargeback and Dispute Allocation
BNPL disputes become difficult when commercial responsibility and payment responsibility do not align.
The provider may assume the customer’s repayment risk, but that does not mean it assumes every loss connected to the sale. The merchant may remain responsible for non-delivery, defective goods, misleading descriptions, cancellation rights, return handling, fraud indicators or evidence failures.
The agreement must state which party owns each dispute type.
A customer may complain to the merchant, the BNPL provider, a regulator or another payment source used to fund instalments. The same purchase can therefore create more than one case reference and evidence deadline.
Build a dispute matrix covering:
- Complaint type
- Responsible party
- Required evidence
- Response deadline
- Financial exposure
- Escalation route
Evidence requirements deserve particular attention. The provider may require fulfilment records, delivery confirmation, customer communication and policy acceptance in a specific format. Evidence that satisfies an internal complaint may not satisfy the provider’s process.
General statements about “fraud protection” are not enough. The contract should explain who carries losses for account takeover, identity fraud, non-delivery, policy violations and late evidence.
Support teams also need a routing rule. They should quickly distinguish product, order, refund and repayment-plan issues rather than sending the customer between two organizations.
Brand Exposure to BNPL Provider Quality
Customers do not separate the checkout experience into legal entities.
If the approval flow is confusing, repayment communication is poor or complaints are handled badly, the merchant’s brand absorbs part of the damage. The customer chose BNPL while buying from the merchant.
This exposure starts with checkout copy. Instalment amounts, eligibility statements and repayment terms must be clear. Vague “pay later” language can create complaints when customers later discover conditions they did not understand.
It continues through support. The merchant needs a direct escalation path rather than a generic provider queue. Customers who have already contacted both parties should not be asked to repeat the same case.
Collections and late-payment communication can also affect how the customer remembers the purchase. Even where the provider owns the credit relationship, poor treatment can reduce repeat purchase and produce negative reviews aimed at the merchant.
Provider due diligence should therefore include customer experience, not only approval rates and merchant pricing. Review customer-facing terms, decline messaging, repayment reminders, complaint standards, refund visibility, response times and language coverage by market.
After launch, track BNPL-specific support tickets, complaint themes, review mentions and repeat-purchase behaviour. A provider can improve conversion at checkout while weakening customer value afterwards.
Cash Flow and Settlement Timing Risks
BNPL is often described as immediate merchant payment while the provider collects from the customer later. Actual cash availability depends on the agreement.
Settlement may occur on a fixed schedule, after capture, after shipment or after another event. Fees may be deducted before payout. Refunds, disputes, reserves, holdbacks and negative balances can reduce later settlements.
Finance teams should review:
- Settlement frequency and trigger
- Reserve and holdback rights
- Negative-balance treatment
- Refund funding
- Dispute deductions
- Currency and conversion points
- Reconciliation file timing
- Rights to change terms or delay funds
A merchant with high seasonal volume may become dependent on BNPL payouts to fund inventory or fulfilment. If the provider increases a reserve or delays settlement during a refund spike, the impact can be larger than the transaction fee.
Run a downside cash-flow case before launch. Assume slower settlement, a higher-refund month and a temporary holdback. The business should know how many days of operating cost it can cover without BNPL funds.
Concentration matters as well. BNPL should not become the only practical route for a major customer segment unless the merchant has accepted the continuity risk.
The companion guide on how to implement BNPL without losing margin explains how to test whether conversion and order-value gains justify both the merchant fee and the operating cost.
The Regulatory Backdrop
BNPL regulation is moving toward stronger consumer-credit treatment, but the timing and obligations differ by market.
In the European Union, the revised Consumer Credit Directive broadens the consumer-credit framework and is designed to capture more short-term and low-value credit products. Member states were required to transpose it by 20 November 2025, with the new rules applying from 20 November 2026. The exact merchant impact depends on national implementation, product structure and the responsibilities assigned to the credit provider.
For merchants, the practical issues include advertising, pre-contract information, affordability processes, customer communications and complaint handling.
In the United States, the federal position remains less settled. The Consumer Financial Protection Bureau issued a BNPL interpretive rule in 2024 and withdrew it in May 2025. That withdrawal did not remove general consumer-protection, fair-marketing, privacy, lending or state-law considerations. Merchants still need market-specific review.
Do not hard-code one compliance assumption into a global checkout. Confirm where the customer is located, which entity extends credit, which disclosures appear, who handles complaints, how marketing claims are approved and what records must be retained.
The contract should also state who monitors legal developments, who updates customer-facing flows and who pays for required changes.
Merchants still deciding whether BNPL fits their transaction profile should review is BNPL right for your business before committing technical resources.
Structuring BNPL to Mitigate These Risks
Most BNPL integration risks can be controlled through provider selection, contract discipline, system design and clear ownership.
Select for operating quality
Approval rate and merchant fee matter, but they are incomplete. Compare refund handling, settlement reporting, dispute rules, support escalation, market coverage, platform compatibility and change-management capability.
Ask for sample refund and settlement reports. Test the merchant portal. Confirm whether support can see the same transaction status as finance.
Review the contract against real events
What happens when a customer returns half an order? What happens when the merchant balance is negative? Who loses when evidence is late? Can reserve terms change? What data can the merchant export after termination?
The answers should be written, not assumed from a sales conversation.
Design one source of truth
Every BNPL transaction should connect to one internal order ID. Authorization, capture, refund, dispute and settlement events should update that record without parallel manual spreadsheets.
Duplicate notifications should not produce duplicate fulfilment or refunds. Failed updates should enter an exception queue. Finance and support should see enough shared information to resolve cases quickly.
Define ownership and escalation
Create a responsibility matrix covering product complaints, repayment questions, refunds, fraud, disputes, regulatory complaints, technical incidents and settlement issues.
The merchant needs one accountable point of contact that coordinates with relevant underlying partners when required.
Launch with limits
Start with a defined market, product range or order-value band. Measure refund time, support contacts, reconciliation exceptions, dispute rates and settlement accuracy alongside conversion and average order value.
Expand only when the post-purchase operation is stable.
Working With Vellis on a Well-Structured BNPL Implementation
Vellis approaches BNPL as part of the merchant’s wider payment operation.
As an authorized provider, Vellis reviews the business model, customer geography, transaction profile, average order value, refund behaviour, platform, payment mix and reporting requirements. Vellis then helps structure the appropriate provider relationship and coordinates setup with relevant underlying acquiring, banking and payment partners.
Vellis is not a bank or an acquirer and should not be described as the direct owner of the underlying infrastructure. In some arrangements, Vellis may act as a referral agent. The commercial relationship remains clear: you work with Vellis.
The implementation can cover provider assessment, contract review, refund and dispute mapping, settlement and reconciliation requirements, integration coordination, customer-service ownership, escalation design and controlled launch.
Vellis supports businesses globally, excluding OFAC-listed countries, subject to underwriting, partner requirements and the proposed transaction structure. The MATCH list is the hard eligibility exclusion to state.
BNPL can be a useful conversion tool. It should not create uncertainty around who owes the customer a refund, who owns a dispute, when funds settle or who answers when the standard process fails.
The right setup makes those answers clear before the first transaction.
