
The technical integration takes days. How long it takes to reach first live transaction depends almost entirely on how quickly you move through KYB, not the API itself.
Most teams underestimate this because they conflate two timelines: how long it takes to integrate the API, and how long it takes to go live in production. The first is a developer question. The second is a business question. They have different answers and different bottlenecks.
Phase 1: Sandbox access and first API call
Sandbox access is immediate. Due provides a Python demo script and a Postman collection that walk through the complete managed wallets flow against the sandbox environment. There is no approval gate before sandbox access.
What a developer can verify on day one: that the API works as documented, that responses match the expected schema, and that the specific flow they need exists. The API is REST with standard JSON payloads. Read-only endpoints like FX rates don't even require authentication, so you can inspect live pricing before writing a single line of integration code.
Phase 2: Core technical integration
The API surface a typical neobank or fintech builds against covers four main areas:
- Account creation: Create business or individual accounts for your end users. Each account creation response includes a KYC/KYB link and a terms of service link, so the compliance collection flow is built in from the start.
- Transfers: Quote, create, and execute transfers. Quotes lock the rate for two minutes. The same endpoint handles fiat-to-fiat cross-border, fiat-to-stablecoin on-ramps, stablecoin-to-fiat off-ramps, and stablecoin swaps.
- Virtual accounts: Create dedicated receiving accounts in EUR, GBP, USD, MXN, AED, BRL and more. Funds arriving via local rails convert automatically to the target currency or asset.
- Webhooks: Subscribe to transfer status events, KYC status changes, and incoming deposit notifications.
The complexity of this phase scales with the number of flows you need. A single on-ramp use case is straightforward. A multi-directional product covering on-ramps, off-ramps, cross-border fiat payouts, and stablecoin swaps requires more testing surface.
Phase 3: Platform KYB, the rate-limiting step
Before Due activates your platform for production, your business goes through KYB. The process covers company registration, ownership structure, associated parties (directors, UBOs), corporate documents, and a risk questionnaire. Once submitted, it routes to manual review by Due's compliance team.
This is where timelines diverge most significantly across teams. The docs describe the process in detail but do not publish a review SLA. Actual review time is something to confirm directly with Due during onboarding. What the docs do make clear: the review is a real manual step, and the outcome can be an approval, a request for additional information, or a rejection.
- What compresses this phase: document packages prepared in advance, clean ownership structures without complex UBO chains, and submitting KYB in parallel with technical work rather than after it.
- What extends it: incomplete submissions, entities with multiple layers of ownership, and jurisdictions requiring enhanced due diligence.
Phase 4: Production testing
Moving from sandbox to production requires more than switching environment URLs. A testing checklist typically covers:
- End-to-end live transaction testing per corridor
- Webhook reliability and retry behavior under real conditions
- Error handling for declined payments, KYC/KYB failures, and transfer exceptions
- Quote expiry handling: confirming your UX correctly manages the two-minute window and expired rate scenarios
- Reconciliation: confirming your internal records match Due's transaction records
The scope of this phase is proportional to your corridor coverage. Testing one corridor and one flow type is a different undertaking than testing ten currencies across multiple rail types.
First live transaction
The honest answer is: it depends primarily on KYB turnaround. Teams that submit complete KYB documentation early and run technical integration in parallel get to first live transaction faster than those that treat compliance as a post-integration step.
What determines your timeline
The API itself is not where time is lost. KYB document preparation and internal compliance review are the two factors teams most consistently underestimate.
The comparison: single API vs. building direct rails
The phases above apply to integrating a single-API provider. Building direct banking relationships and licensing corridor by corridor operates on a different order of magnitude.
Getting a US money transmitter license across all 50 states takes 12 to 24 months. Fees, bonds, and legal costs exceed $1 million before you process a single transaction. California alone takes 12 to 18 months to process an application. The EU, LATAM, and APAC each add separate licensing tracks. For a full breakdown of that comparison, see how fintechs handle cross-border payments without building in-house.
How Due's integration works in practice
Sorbet, a payments platform for freelancers and SMBs across MENA and Africa, needed payouts in SAR, AED, KES, INR, PKR, and EGP at launch. Rather than building a separate banking relationship per currency, they integrated once with Due's API and launched across 80+ markets through a single connection.
As co-founder Maher Ayari put it: "Due already had the payment rails and compliance infrastructure in the markets we wanted to expand into. That allowed us to move faster, launch confidently, and scale our global payment capabilities without rebuilding the connectivity layer ourselves."
What a single Due integration covers
- 80+ countries with local rail access: SEPA, ACH, PIX, SPEI, Faster Payments, mobile money, and SWIFT
- Stablecoin settlement in USDC, EURC, and USDT, in under three minutes, 24/7
- Virtual accounts in EUR, GBP, USD, MXN, AED, BRL and more
- Built-in compliance: KYC/KYB, AML screening, and regulatory registrations across the EU, UK, Canada, US, and LATAM
Book a demo to understand how the integration maps to your specific corridors and use case.



