A stablecoin payments API can look identical to three competitors on a sales call. Same talking points: multi-currency support, fast settlement, built-in compliance. The differences that actually matter only show up once you start asking for evidence instead of claims. By the time most teams discover a gap, they have already built against the API.
This article walks through what to verify before committing engineering time to an integration, organized by the questions that separate production-ready infrastructure from infrastructure that sounds production-ready.
Start with regulatory authorization, not regulatory language
Almost every provider in this space describes itself as "compliant" or "regulated." That phrase means nothing on its own. What matters is which specific entity holds which authorization, and which regulator issued it. You also need to confirm that authorization actually covers the activity you need.
For stablecoin services in the EU, the relevant authorization is MiCA CASP, granted by a national competent authority and passported across the EU and EEA. For US-facing activity, the relevant question is state-by-state money transmitter licensing or a clearly defined bank partnership. For other markets, it is a registered VASP or equivalent status with the local financial intelligence unit or central bank.
The verification step is simple. Ask for the legal entity name, the registration or license number, and the regulator. For EU providers, check that registration directly on the ESMA Interim MiCA Register, rather than taking the provider's word for it. If a provider cannot produce this within a single email, that is itself useful information.
Match coverage to your actual roadmap, not their marketing map
A "80+ countries" headline number is not the same as coverage in the specific corridors you need at launch and over the next 12 months. This is the same evaluation question underlying the broader build versus single-API decision. Two questions matter more than the total count.
- Does the provider support local rails in your priority corridors, or do some markets route through SWIFT correspondent banking by default? Local rail access (SEPA, PIX, SPEI, Faster Payments, mobile money) is materially faster and cheaper than correspondent banking. Not every "supported country" gets the same rail treatment.
- Is stablecoin settlement available end-to-end, or only on one side of the transaction? Some providers handle the on-chain leg well but rely on a third party for fiat off-ramp in specific markets. That reintroduces a dependency you did not know you had.
Ask for the corridor-level rail map, not just the country list.
Test the API itself before testing your own code against it
Before writing integration code, spend an afternoon in the provider's sandbox doing nothing but reading responses. For a full breakdown of what the path from sandbox to live transaction actually involves, see how long it takes to integrate a cross-border payment API. A few things to check directly:
- Does sandbox access require approval, or is it instant? A provider that gates sandbox access behind a sales conversation is optimizing for pipeline, not developer evaluation.
- Are quotes and pricing visible without a contract? A transparent FX quote endpoint should show you the exchange rate, the markup, and the quote expiry window before you have signed anything. If markup is only disclosed after a commercial agreement, that is a pricing transparency problem you will not be able to fix later.
- Does the documentation match the actual API behavior? Run the example requests from the docs verbatim. Mismatches between documented and actual responses are a warning sign. They indicate how well-maintained the rest of the integration experience will be.
Check the security model for fund-moving credentials, specifically
For an API that moves money or holds wallet infrastructure, generic claims of "bank-grade security" are not a substitute for understanding the actual credential model. The questions to ask:
- How are API credentials created and rotated? A sound model requires you to generate and register your own private key as a credential, rather than the provider issuing you a static secret you cannot rotate independently.
- What happens if a credential is compromised? Look for a model where adding a new credential requires approval from an existing approved credential. That way, a single compromised key cannot add new access on its own.
- Who can access wallet funds? If the provider hosts wallet infrastructure on your behalf, ask directly. Does the provider itself have any path to wallet funds, or can only your registered credentials authorize operations?
These are mechanical, verifiable details. A provider with a real security architecture can answer all three specifically. A provider repeating "enterprise-grade security" without specifics on credential handling has not answered the question.
Verify the compliance infrastructure does what it claims
Built-in KYC/KYB is a standard claim. What varies is depth. Ask specifically:
- What KYC/KYB provider do they use, and is it a recognized name in regulated fintech, rather than a homegrown or unnamed system?
- Is sanctions screening continuous, or a one-time check at onboarding? Ongoing monitoring matters more than point-in-time screening for any platform with recurring users.
- Does the provider publish a list of prohibited jurisdictions and restricted industries? A defined, public exclusion list shows a provider has thought through its own regulatory exposure.
- What does the KYB rejection and appeal process look like? You will eventually have a legitimate customer rejected incorrectly. Knowing the resolution path before you need it matters.
Get specific about settlement reliability, not just settlement speed
"Instant settlement" is a marketing phrase. The operational questions underneath it:
- What is the actual webhook and status event system for tracking a transfer from creation to completion? Real-time status visibility through webhooks, not polling, is the baseline for production reliability.
- What happens on a failed or stuck transaction? Ask for the specific error handling and retry behavior, not a general assurance that "the team will help."
- Does the provider publish uptime data or incident history? Many providers in this space do not publish a formal uptime SLA. If that is the case, ask directly during evaluation rather than assuming a number. Treat the absence of a published figure as something to confirm, not something to ignore.
Pricing: model the total cost at your actual volume, not the headline rate
A quoted "near-zero spread" or "X basis points" figure is incomplete on its own. You need to model it against your specific currency pairs and volume. Two providers with similar headline pricing can produce very different total costs. The difference comes down to which currency pairs carry higher markup, whether there are minimum monthly fees, and whether pricing changes at volume tiers. For a breakdown of where these cost layers actually come from, see how neobanks reduce cross-border payment costs at scale.
Request a full fee schedule across your specific corridors, not a single representative example, and build your own cost model before comparing providers on price.
Red flags to watch for during evaluation
A few patterns are worth treating as warning signs rather than minor friction:
- Compliance claims without a specific registration number. "MiCA compliant" or "fully regulated" without a named entity, license number, and regulator is marketing language, not a verifiable fact. Ask for the specific reference and check it yourself.
- Sandbox access with no clear production path. If a provider cannot describe what production onboarding (KYB review, go-live testing, account activation) actually involves, the production experience likely has not been built out as thoroughly as the sandbox demo
- Pricing that only becomes clear after a signed agreement. Transparent providers can show you a real quote, including markup, before you commit to anything.
- No answer on credential or key security specifics. Vague reassurance instead of a description of the actual credential model is a meaningful gap for any API that touches funds.
- No defined process for compliance edge cases. If a provider cannot describe what happens when a KYB application is rejected, or a transaction is flagged, that process gap becomes your operational problem after launch, not before.
The consolidated checklist
Use this as a working list during vendor calls and documentation review.
Regulatory and compliance
- Specific legal entity name, registration number, and regulator for each jurisdiction you operate in
- Confirmed directly on the regulator's public register, not just the provider's claim
- Published list of prohibited jurisdictions and restricted industries
- Named KYC/KYB provider and confirmation of continuous, not one-time, sanctions screening
- Defined KYB rejection and appeals process
Coverage
- Corridor-level rail map, not just a country count, for your specific priority markets
- Confirmation of which side of fiat-to-stablecoin and stablecoin-to-fiat flows are natively supported versus routed through a third party
Technical and security
- Sandbox access without a sales gate
- Documentation that matches actual API behavior on a test run
- Credential creation model: self-generated keys, not static provider-issued secrets
- Multi-credential approval process for adding new access
- Explicit confirmation of who can authorize wallet fund movement
Reliability
- Real-time webhook-based status tracking, not polling-only
- Documented error handling and retry behavior for failed transactions
- Direct answer on uptime data or incident history, even if no formal SLA is published
Pricing
- Visible FX quote with markup disclosed before any contract is signed
- Full fee schedule across your specific corridors and volume tiers
- A cost model built against your own currency pairs and projected volume, not the provider's representative example
How Due answers these questions
Due's regulatory structure spans multiple entities, each with a named registration:
- Due Network, S.L.: registered with the Bank of Spain (registration number E167) and holds MiCA CASP authorization from Spain's CNMV, supervised by SEPBLAC
- Due Payments EOOD: registered with Bulgaria's National Revenue Agency as a virtual assets service provider
- Due Payments Inc.: registered with FINTRAC in Canada as a Money Service Business (MSB registration number C100000185)
Each entity and registration is published on Due's regulatory disclosures page.
On geographic coverage, Due publishes its prohibited jurisdictions and restricted industries directly, rather than leaving compliance scope ambiguous.
On security, Due's wallet infrastructure requires you to generate and register your own credential before any wallet operation. Adding additional credentials requires approval from an existing approved credential. This model is built so a single compromised key cannot move funds on its own.
Book a demo to walk through this checklist against your specific corridors and compliance requirements.
