Local Payment Methods: Why Integrate a Hundred Ways to Pay?
Part II · Extensions to the Architecture (Chapters 6–8) Builds on: Payment Systems, Chapter 12 (local methods, front-end aggregation and approval rates). Beyond Cards: Local Payment Rails and QR Codes explains the rails themselves; this chapter examines how PSPs integrate them. New concepts in this chapter: four attributes of local payment methods, direct integration, aggregation, orchestration, asynchronous results, local settlement currency
1. The question from the previous chapter¶
StarMap's Dutch users pay with iDEAL, Brazilian users with Pix, Indian users with UPI, and many Southeast Asian users by scanning a QR code. Most are push-based and lack card-style chargebacks. Yet they need checkout integration, payment confirmation and refunds, extending the receive-and-identify service in pay-in endpoints.
What are these methods? Start with four examples.
2. How iDEAL, Pix, UPI and direct debit work¶
StarMap shows a different payment button in each market. Clicking each starts a different process:
| Method | Direction | Where the user confirms | When the merchant learns the result | Refund mechanism | When the merchant receives funds |
|---|---|---|---|---|---|
| Netherlands: iDEAL | Push | Redirect to the user's banking app | Seconds after confirmation, through iDEAL | A separate merchant-initiated transfer in the model described here | Same or next day, through the collecting bank |
| Brazil: Pix | Push | Scan a QR code or copy payment data into the banking app | Seconds, through Pix | A dedicated instruction returning funds through the original payment route | Immediately |
| India: UPI | Push; recurring debits have a separate mandate model | Enter a PIN in a UPI app | Seconds | A dedicated refund instruction through the original route | Immediately into the recipient's bank account |
| Germany: SEPA direct debit | Pull | Sign a mandate once, then allow recurring collections | Return outcomes emerge over days after submission | Merchant refund; the payer also has an eight-week no-questions-asked refund right | After several days |
Two relationships matter.
First, these methods connect checkout to the payment process. The user's confirmation must produce a status the merchant can use. For instant push methods that usually happens within seconds; direct debit remains subject to later outcomes. This differs from a basic pay-in endpoint that waits for a bank receipt and then identifies it.
Second, the methods vary along four attributes: direction, confirmation experience, refund mechanism and settlement speed. Card schemes provide a broadly standardized framework across markets; local methods each have their own combination.
The industry groups these non-card options as local payment methods, or LPMs. In this course:
A local payment method combines a local rail, a confirmation step that connects it to checkout, and that rail's refund and settlement rules.
Beyond Cards explains individual rail mechanisms. Here we focus on integration by the PSP.
3. Why offer a hundred methods?¶
Domestic and global payments explains why missing local methods can mean missing much of a market. iDEAL dominates Dutch online shopping in the period described; Pix rapidly became a mainstream Brazilian online method; UPI is central to India's small online payments. A card-only StarMap checkout reaches only part of the customer base in those markets.
Each method can require:
- A separate agreement with a bank association, central bank or private company.
- A separate technical interface and status notifications.
- Its own refund rules.
- Its own reconciliation format and settlement cycle.
- Sometimes a local legal entity and bank account.
Integration costs accumulate with the number of methods, because each brings a separate contract, technical connection and settlement arrangement. A PSP covering 30 countries may need to maintain 100 methods.
That accumulating cost creates demand for providers offering many methods through one integration.
4. Direct integration, aggregation and orchestration¶
There are three ways to put an iDEAL button on StarMap's checkout:
| Path | Who contracts for iDEAL access? | Integration chain | Who holds local permissions? | Per-payment cost in this comparison | StarMap's control over status and refunds |
|---|---|---|---|---|---|
| Direct integration | StarMap's PSP | PSP connects to iDEAL; StarMap connects to PSP | PSP | Lowest | Strong: the PSP receives rail status directly |
| Aggregation | A specialist aggregator | PSP connects once for many methods; StarMap still connects only to PSP | Aggregator | Medium: an additional markup | Medium: another intermediary separates it from the rail |
| Orchestration | StarMap maintains multiple PSP relationships behind a routing layer | StarMap connects to the orchestrator, which connects to multiple PSPs | Each PSP | Highest in this simplified comparison: PSP and orchestration charges | Strongest choice: StarMap can switch PSPs by country and performance |
Examples illustrate the roles:
- Direct integration: large PSPs such as Adyen, Stripe and Checkout.com connect directly in major markets. Success rates and direct status visibility are part of the value.
- Aggregation: PPRO packages many local methods for PSPs rather than serving merchants directly. dLocal and EBANX specialize in emerging markets across Latin America, Africa and Asia: local entities and permissions, local-currency collection, then conversion and settlement to overseas merchants.
- Orchestration: Primer, Gr4vy and Spreedly sit on the merchant's side, connecting multiple PSPs and selecting routes by country, method and observed performance. Large merchants may build this layer themselves.
The distinction is who bears the integration cost. Direct integration places it with the PSP and gives direct control. Aggregation concentrates the work in a specialist and spreads the cost across clients, accelerating coverage. Orchestration gives the merchant provider choice while adding a layer. Concentrated high volume favors direct integration; dispersed coverage favors aggregation; large merchants often use orchestration.
5. Licensing requirements: each method has its own entry rules¶
Cards use a common scheme framework alongside payment regulation. For local methods, the operator of each system sets its access rules:
| Method | Who sets access rules? | What an entrant needs |
|---|---|---|
| iDEAL and SEPA direct debit | Their scheme bodies: European Payments Initiative (EPI) for iDEAL; European Payments Council (EPC) for SEPA direct debit | Appropriate EU payment-institution or bank permissions |
| Pix | Central Bank of Brazil | For direct access, the relevant local authorization and entity; otherwise access through a participating bank or payment institution |
| UPI | National Payments Corporation of India (NPCI) | Third-party apps work through an Indian bank; merchant aggregation also requires the relevant Reserve Bank of India permission |
| Cross-border Alipay and WeChat Pay | The two companies | Cross-border merchant agreements and access through recognized partners; users pay renminbi and merchants receive foreign currency |
| Domestic wallets | Each wallet operator | Individual commercial agreements, often with a local entity or partner |
Operators may be central banks, industry bodies or private companies, so there is no single entry standard. Compared with the clearing access in pay-in endpoints, where public eligibility rules play a central role, local-method access can also depend heavily on commercial negotiation.
Another requirement appears at settlement: many emerging-market currencies cannot simply be remitted abroad without local FX and reporting steps. StarMap collects rupees in India or reais in Brazil, but needs usable dollars or euros. The provider must convert locally and remit under local rules. This uses the payout endpoint mechanism in the outbound direction: convert funds from the local pool and pay an overseas account. For dLocal and EBANX, the conversion-and-remittance capability is as significant as local collection access.
6. Engineering requirements: asynchronous results, refunds, files and currencies¶
Asynchronous results
When a user leaves checkout for a banking app, they may never return. They may have paid, abandoned the payment or completed it ten minutes later. The PSP must learn the result through notifications or queries. It needs to handle an on-time notification, a missing notification followed by eventual receipt, and a success notification without corresponding funds. The last case is especially dangerous if the merchant has already delivered the product.
Different refund mechanisms
The earlier table shows different refund arrangements. A PSP may expose one Refund button while implementing a method-specific operation behind it: refund through the original route, send a separate transfer, or handle an unsupported refund manually. Refund states and reconciliation must also follow each method's rules.
Reconciliation files
Each operator provides files in its own format and on its own schedule. The PSP normalizes them into an internal format and performs the three-way reconciliation described in pay-in endpoints. The difficulty is ongoing coverage: every method adds work, and every operator format change requires an update.
Local settlement currency
StarMap's Indian collections may first become a rupee balance, then be converted and remitted on an agreed cycle before reaching its dollar balance. FX, timing and reporting sit between those events. StarMap might see a ₹1,000 customer payment followed two days later by an illustrative $11.50 credit. Behind that simple result, the provider performs a sequence of payout endpoint operations.
| Engineering issue | Cards in this comparison | Local payment methods |
|---|---|---|
| Asynchronous results | Authorization usually returns synchronously | Common for redirect-based push methods |
| Refund differences | A common scheme framework | Method-specific rules |
| Reconciliation files | Scheme-standard formats | Separate format per method |
| Local settlement currency | Schemes support multicurrency settlement | Emerging-market collections often settle locally before conversion and remittance |
7. Put local methods back into the model¶
Within the PSP model, an LPM is a variant of the pay-in endpoint. It collects locally, identifies the merchant and tells the core to post funds. It adds checkout interaction and method-specific refund and settlement rules. A pull method, such as direct debit or an automatic wallet debit, also adds dispute responsibilities of the kind discussed in acquiring. These rails can support outbound payments too, including payments to Pix details, a UPI account or a wallet. That is a payout endpoint using another rail; this course reserves LPM for the merchant-acceptance context.
The three components also explain a provider such as dLocal: local pay-in endpoints across emerging markets, each with an entity, permission and account; a core recording overseas merchants' local-currency entitlements; and payout endpoints delivering converted dollars to merchants abroad. The product is the combination of all three.
8. The questions this raises¶
StarMap can now collect through transfers, cards and local methods, with proceeds recorded in the balance core.
It also needs to spend. Hotels and software vendors accept cards, but StarMap's PSP balance is not yet linked to a card. The next chapter explains issuing: turning that balance into something employees can spend at card-accepting merchants.
9. Self-check questions¶
- A PSP offers iDEAL at checkout without its own EU payment licence. Which integration path is most likely, and who supplies the permission?
- A Brazilian user pays StarMap R$100 over Pix, but StarMap's dollar balance increases three days later. What might the PSP do during that interval?
- Why do local-method integration costs accumulate by method, while card-scheme integration scales more uniformly across markets? What strategy follows for a PSP entering 30 markets?
10. Answers¶
Try answering before reading on.
Aggregation. A licensed aggregator contracts for iDEAL access and supplies the payment result and settlement to the PSP. The PSP itself is not the direct participant. Direct integration would require its own relevant permissions; orchestration is a merchant-side provider-selection arrangement.
The Pix endpoint receives R$100 and identifies StarMap. The provider converts the local funds into dollars on the agreed cycle and performs the relevant Brazilian FX reporting and remittance steps. Once dollars reach the overseas account, the core records StarMap's dollar entitlement. The delay is chiefly conversion and remittance, rather than Pix processing.
Card schemes reuse a broadly common technical and rule framework across markets, while each local method brings another contract, interface, refund process and reconciliation format. Unless volume is high in every new market, a PSP should connect directly in a few major markets and use aggregation for the rest, considering direct access later as individual markets grow.
Previous: Chapter 6 · Acquiring: From a Collection Account to Merchant Transactions Next: Chapter 8 · The Issuing Ecosystem: Turning a Balance into a Card