The Philippines has passed an estimated 80 million registered e-wallet accounts in 2025, a threefold rise in five years. Across Southeast Asia, digital wallets now account for close to 40% of e-commerce payment value. Lenders who cannot disburse to a wallet in real time, collect through a gateway reliably, and check a bureau inside the application flow are going to struggle in the competitive markets. This walkthrough covers how each integration actually works, the failure modes that appear only in production, and what a core has to provide for any of it to hold at scale. 

Why integrations fail post-launch

The connection itself is rarely the hard part. The operational detail around it is. As one payment-integration guide puts it, integrations fail because teams underestimate the operational detail around it: a basic integration processes a payment fine in a sandbox, and production is a different animal. Users refresh pages. Mobile networks drop mid-transaction. A customer taps pay twice. A charge succeeds but the front end never sees the response. The provider retries an event you already processed. 

These are not edge cases in emerging markets. In production systems processing real volume, payment failure rates commonly run between 5% and 15% depending on the market and method. An integration that assumes the happy path will spend its first month in production generating reconciliation breaks and support tickets. Designing for failure is the work. 

Three things separate an integration that survives production from one that falls over 

1. When a message gets sent twice, which happens all the time, the system needs to recognise the repeat and act on it only once, so a customer is never charged or paid twice 

2. The system should be told the moment something changes, instead of having to keep asking 

3. You need a routine check that assumes two systems will disagree at some point and catches it when they do 

Integrating wallets: disbursement and collection in real time 

Wallets are where customers in these markets hold and move money: GCash and Maya in the Philippines, GoPay, OVO and DANA in Indonesia, OPay and PalmPay in Nigeria. For a lender, the wallet is both the disbursement destination and the repayment source, and each direction has its own failure surface. 

Disbursement 

When a loan is approved, the funds have to reach the customer’s wallet through the right rail, InstaPay in the Philippines, the relevant local scheme elsewhere, and the customer expects it in seconds. The disbursement call is asynchronous: the core requests the transfer, the wallet or rail accepts it, and the final confirmation arrives later through a webhook. The mistake is treating the initial acceptance as success. The transfer is not complete until the confirmation event lands, and the core has to hold the disbursement in a pending state until it does, then reconcile. 

Collection 

Repayment is harder, because the customer initiates it and the timing is theirs. A collection either pulls from the wallet on a schedule the customer has authorised or waits for a customer-initiated push. Either way, the confirmation is again a webhook, and again the core must not mark a loan repaid until the money is confirmed to be settled. The most common production bug here is optimistic posting: recording the repayment when the customer says they have paid, before the settlement event confirms it, which quietly corrupts the loan’s state. 

Core rules for survival

Real-time disbursement and collection depend on the core being able to receive and act on events as they arrive, not on a nightly file. Every wallet transaction has to update the account record the moment its confirmation lands, and every state has to be able to handle duplicate messages, because wallets and rails guarantee at-least-once delivery and will resend a confirmation you already handled. A core that only ingests wallet activity through a batch import cannot support a real-time product, however good the wallet API is. 

Integrating payment gateways: accept, settle, reconcile 

Gateways such as Xendit, Midtrans and DOKU in Indonesia, PayMongo in the Philippines, and Paystack and Flutterwave in Nigeria handle card and bank-transfer acceptance and settlement. The integration pattern is well established, and the failure modes are well documented enough that they should never be a surprise. 

Webhooks 

A customer completing a payment gets redirected back to your app, and it is tempting to treat that redirect as confirmation. It is not. The customer can close the tab before the redirect fires, or the payment can succeed while the redirect fails. The authoritative confirmation is the gateway’s webhook, which must be verified cryptographically before it is trusted. Grant access to the paid product on the webhook, not on the redirect. 

Reconciliation  

Webhooks are delivered reliably, not perfectly. Endpoints go down, events are missed, and a reconciliation job that polls for anything the webhooks did not deliver is what keeps the ledger honest. The payoff is measurable: automated webhook-driven reconciliation has been shown to cut discrepancies from 5–8% in manual systems to under 0.1%. Build the reconciliation job on day one, not after the first month-end that will not balance. 

Integrating credit bureaus: real-time checks inside the application flow 

Credit bureaus, CIC in the Philippines, SLIK and Pefindo in Indonesia, CRC and FirstCentral in Nigeria, are a different kind of integration. This is not a money movement. It is a synchronous decision input, and its whole value depends on speed and on consent. 

Speed limits

A bureau check embedded in an automated underwriting flow, where an agent or a scorecard is making a decision in real time, has a hard speed limit: the response has to return inside the window that keeps the borrower in the application. A bureau API that answers in tens of seconds cannot sit in a real-time decision. The integration has to be built to call the bureau, hold the decision open for a defined interval, and act on the response, with a defined fallback for when the bureau is slow or unavailable. 

Consent and audit are part of the integration 

A bureau pull is regulated. The customer’s consent to the check has to be captured, recorded, and linked to the pull, and the whole exchange has to be auditable after the fact. This is not a wrapper around the API call. It is part of the integration, because a decision made on bureau data the institution cannot prove it was entitled to pull is a decision the regulator will question. The record of what was pulled, when, with what consent, has to persist alongside the decision it informed. 

Fallback must be part of the design decision

If a bureau goes down, the institution needs a defined answer to the question of what happens to an application in flight: decline, hold, or decision on alternative data. That answer is a policy the institution owns, and the integration has to make it configurable, because the right fallback differs by product and by risk appetite. An integration that simply errors when the bureau is unavailable hands the outcome to chance. 

Why this is a core problem, not an integration-team problem 

Each of these integrations can be built as a one-off. The trouble is that a bank or lender needs wallets and gateways and bureaus, across more than one market, each with local providers, and it needs to add the next one without a bespoke project every time. A lender launching in the Philippines with GCash, Maya, PayMongo and CIC has four integrations before it writes a line of product code. Indonesia is another four, and Nigeria is another four. If each of those is a discrete engineering effort, expansion is priced in quarters and headcount, and the launch date is a guess. 

Two properties of the core decide whether that number falls. The first is whether the core can be reached and driven entirely through APIs. Partial coverage, where the easy reads are exposed and the consequential actions stay locked behind a screen, means every integration hits a wall at the point where it needs to do something. An integration that can originate a loan, post a transaction and update a limit through the API is an integration a team can finish. One that cannot is a project that stalls, gets escalated, and takes a workaround into production that someone will be maintaining in two years. 

The second is whether the core is event-driven. Every integration above depends on reacting to something that happened elsewhere: a disbursement confirmed, a payment settled, a repayment received. A core that publishes its own events in real time and consumes external ones the same way lets a team build a new connector against a known pattern. A batch-based core forces every real-time integration into a workaround, and the workarounds are where the double-postings, the reconciliation breaks and the support tickets come from. That cost lands after launch, on the same team you wanted building the next product. 

This is what 100% API coverage means; complete coverage means every function is reachable through it and every event flows through it, so a new wallet, a new gateway or a new bureau is a configuration and a connector rather than a quarter of engineering. The practical difference is whether adding a provider is a two-week piece of work a product team can schedule, or a discovery exercise that goes into next year’s roadmap. Oradian is built this way: an API-first, event-driven core where the integration surface is the whole platform, with connectors to the wallets, gateways and bureaus that matter in emerging markets built against exactly the failure modes described here. 

Get a core that makes integrations easy

If wallet, gateway and bureau connections keep turning into bespoke projects, your core is probably your problem. Talk to our team about what complete API coverage and real-time event streams would mean for your markets, at vanda.jirasek@oradian.com