How to evaluate a stablecoin API in 30 days: sandbox to live

Evaluating a stablecoin API in 30 days means giving each week one job: shortlist providers in writing in week 1, test sandboxes against failure cases in week 2, run compliance and commercial review in week 3, and pilot small live payouts on one corridor in week 4. Decide on day 30 from measured results.

Every provider claims quotes and global rails. The differences show when a quote expires, a payout is rejected or finance closes the month, and this plan surfaces them on a fixed clock with the pass rule written first. It is a frame, not a promise: how long KYB (know your business, the verification of a company and its owners) and a first live payout take depends on the provider and your paperwork. To decide what kind of provider you need first, read what a stablecoin API is and how to choose an infrastructure provider.

Five owners, five sign-offs

Engineering alone decides what compliance or finance must undo. Name five owners on day one: engineering signs off on the week 2 test table, compliance on the responsibility split in writing, finance on the cost model and pilot reconciliation, operations on the support runbook, and product on the final decision.

Week 1: write the requirements, then cut the list to three

Put the requirements on one page: corridors, rails, monthly volume, typical payout size, who holds funds at each step and who verifies your end users. Drop every provider that does not do that job, since a card issuer, a consumer on-ramp and a payout API are different products. Send the rest one fixed list of questions; the RFP template has the long version. Ask for sandbox access, an itemized sample quote for your top corridor at your typical amount, the standard contract and the licensing summary on day one. Start each shortlisted provider's KYB or onboarding paperwork that same day and ask in writing for production access and its lead time, since both run until week 3.

Pass rule: two or three providers with written answers, sandbox access, a sample quote and a written lead time for production access. The red flag is a sales call required before you can see a sandbox; a call for production access is normal, so record its lead time. Other early disqualifiers are in stablecoin payments provider red flags.

On Lumx, the sandbox is open and self-serve, with every currency enabled, and production access is a conversation with the team, so ask for it on day one. The pricing model is one sentence: monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, no pre-funding; no published plans. Check requirements against the coverage page.

Which failure tests belong in week 2?

All of them, before any happy path counts as done. Every sandbox can complete a payout; the test is whether your system ends each unhappy case in the right state without hand fixes.

Fourteen sandbox tests, each with a pass rule you can count.

Count failures, not passes: a case you cannot provoke is a branch you would write blind, so log it. The steps are in how to integrate a stablecoin API, and the causes of a bounced payout in why stablecoin payouts get rejected.

On Lumx, the sandbox runs on testnet against mock banking partners, so no real money moves. The last digit of a customer's taxId drives verification: a 2 returns RFI (request for information, a compliance hold that asks for a document), a 3 returns FINAL_REJECTION, and most others return APPROVED. The docs name the rest: a repeated Idempotency-Key with the same body returns the cached response, and another body returns a 409. A locked rate raises EXCHANGE_RATE_EXPIRED or EXCHANGE_RATE_ALREADY_USED, a payout above the balance returns INSUFFICIENT_BALANCE, and one above a limit returns TRANSACTION_LIMIT_EXCEEDED. Match on the code, never the message. A retry during processing returns 409 IDEMPOTENCY_KEY_IN_FLIGHT, failed responses are cached, and a key expires after 24 hours, so run test 8 inside that window. Webhooks are signed with HMAC-SHA256, and the docs sample rejects messages older than 5 minutes. Rate limiting returns 429 TOO_MANY_REQUESTS with no published limit, so back off. A destination with invalid details is rejected at creation, and a payout needs an approved destination: verification includes sanctions screening and the banking partners' name check (VoP or CoP), which counts toward approval without a separate verdict, and a SELF destination is checked on the name too. A regular on-ramp in the sandbox follows its full flow, so the deposit can be simulated. The production checklist prompt audits what changes afterward.

Week 3: compliance and commercial review

Week 3 is the review and sign-off of the paperwork you started on day one: who is authorized to do what, and what the contract says when something goes wrong. Check public registers instead of trusting a slide, such as the BCB list for Brazil and FinCEN's MSB registration for the US, and write down who runs KYB, KYC (know your customer, the verification of an individual), sanctions screening and monitoring for your flow; the KYB explainer lists what providers ask of a company, and the onboarding flow guide shows it inside a product.

Collect seven things: the dated authorization status, the split of KYB, KYC, screening and monitoring, how customer funds are held and segregated, the monthly minimum with any ramp-up, the limits per customer and how to raise them, the export and termination terms, and the latest security report with the incident process.

Pass rule: the responsibility split is signed, and finance has written pricing for the pilot corridor.

On Lumx, KYC runs through Sumsub, every transaction is screened before it executes, Chainalysis KYT monitors blockchain activity for every type of wallet, and fiat uses Lumx's own systems plus banking-partner oversight. Lumx is compliant with SOC 2 and ISO 27001 (not yet certified), runs penetration tests, and publishes a service level agreement. KYB targets one business day once all documents are in, a target and not a promise. In Brazil, Lumx SPSAV Ltda filed its application for the SPSAV authorization (Sociedade Prestadora de Serviços de Ativos Virtuais, the company type that holds Brazil's virtual asset service provider authorization) and operates under the transition regime of Resolution BCB 520 of 2025, Article 88, as of November 1, 2026. Wallets are custodial, held by BitGo with a separate wallet per customer and no omnibus account. The standard contract covers returning funds on exit and an export of history and addresses. There is no setup fee, and the standard agreement has a monthly minimum that a ramp-up period waives in the first months. A customer's limits are readable with includeTransactionLimits=true, and a higher limit goes through Enhanced verification.

Week 4: pilot real payouts on one corridor

Run small real amounts on one corridor and record everything. A sandbox skips the bank leg, where a SWIFT payment picks up correspondent banks, extra days and unquoted fees, and where settlement time, support quality and reconciliation turn into numbers. Pay your own recipients first, cap each payout at an amount whose delay you could accept, add real recipients once those reconcile, and time one real support question.

I would put the rejected payout at the top of the pilot log, not the bottom. A payout to a deliberately wrong account number should be refused at creation, and how the provider says so tells you more about the next year than ten clean payouts. My recommendation is to ask every shortlisted provider for that same case in week 4, and to score the answer. I would also start compliance and contract review on day one instead of in week 3, because it is the one workstream you cannot speed up by working harder once it starts.

Log every pilot payout with the same fields for every provider: identifiers, amount sent and received, the reference rate at quote time, three timestamps, the rail reference and the status history. As an illustrative working floor, ten payouts per rail give a rough median, not a statistical result. Reconciliation of stablecoin transactions covers closing the books, and payout limits and cut-offs by rail gives timings to compare against.

Pass rule: every pilot payout is completed and reconciled, or explained.

On Lumx, an off-ramp moves through TRANSFERRING_STABLECOIN, TRADING and TRANSFERRING_FIAT to SUCCESS, with a signed webhook at each change. Every SWIFT payout carries a UETR (the unique end-to-end reference of a SWIFT payment). Pix (Brazil's instant payment system) and SPEI (Mexico's interbank transfer system) run every day with no cut-off, while SWIFT in USD has a 3:00 PM ET cut-off and settles in 1 to 5 business days. Lumx counts an off-ramp as complete once funds leave its banking partner, so get the bank's own time from the recipient. Production uses an IP allowlist, announced in August 2026 with enforcement starting September 21, 2026, so register your server IPs before the first live call.

How do you compare the all-in cost of two providers?

Compare all-in cost on one corridor, one amount and one day: value sent, minus the value that arrived at a reference rate recorded at quote time, plus per-payout fees and the monthly fee spread over your payouts, divided by the amount sent. The spread hides in the exchange rate, so a quote with no fee line can still be the expensive one.

Illustrative arithmetic, not any provider's price: USDC valued at one dollar, a reference rate of 5.00 BRL per dollar, payouts of USD 10,000.

Provider B beats A at 20 payouts and costs 60% more at 4, so run the model at expected volume and in your slowest month, plus the carrying cost of any pre-funded balance. Price pieces are in how stablecoin payout pricing works.

On Lumx, a quote returns the base and final amount and rate, so the spread against your reference is a subtraction. A locked rate holds for 30 seconds, 1 minute or 5 minutes, with a fee only on the longer locks. There is no pre-funding to price, because a payout debits the customer's own wallet.

Decide on day 30 with gates first, then a score

A provider that fails a gate is out, however cheap. Only survivors are scored.

Then score out of 100, with weights you should change.

Attach the pilot log to the decision.

On Lumx, each gate maps to a page you can check: coverage, identity verification and the errors catalog. The global payments page describes the surface the pilot exercises.

When a 30-day evaluation is the wrong tool

If you cannot name the flow, the currencies and the counterparties, the evaluation yields a preference, not a decision, so write the requirements page first. If your volume is small and irregular, integration may cost more than it saves for a year.

What the 30 days look like on Lumx

Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.

Week 1 is the docs, the coverage page and the pricing sentence, plus a sandbox key. Week 2 is the fourteen tests. Week 3 is sign-off on the paperwork started on day one. Week 4 is a live pilot on Pix or SPEI, with SWIFT USD as the slower comparison. Production access is a conversation with the Lumx team, so ask in week 1, not on day 28.

Methodology and sources

The Lumx facts come from the public docs read on November 1, 2026: Identity verification, Idempotency, Errors, Webhooks, Authentication, Exchange rates, Transactions and Payment rail cut-off times. The regulatory status follows Lumx's own statement as of November 1, 2026, citing Resolution BCB 520 of 2025, Article 88, whose official page serves its text through a script, so no claim here rests on its wording.

Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.

Cover photo: Edouard TAMBA on Unsplash.