How I would take card programmes from sandbox to go-live, and a working console that pre-flights a client's authorization endpoint and webhooks against the public Card Issuing spec.
StraitsX is the Visa issuing member, BIN sponsor and issuer processor, with stablecoin settlement. Clients launch a card programme in 12 to 14 weeks and decide each authorization themselves.
Remote Host Authorization. Every Visa auth waits on the client's server for up to 6 seconds, and final outcomes arrive later by webhook. Most go-live risk sits between those two calls.
A console that runs eleven authorization cases against a client endpoint, signs and verifies webhooks, decodes ticket payloads, and drafts the result for the client channel in English, 简体 or 繁體.
| Takeaway | Why it matters for integration |
|---|---|
| Latency is a decline reason | A client endpoint that answers in 6.1 s has declined a cardholder. The CBS_IS_NOT_AVAILABLE rejection reason is the trace it leaves. |
| 2026-09-28 changes every client | idempotency_key becomes a required RHA field. Clients that do not dedupe on it can move money twice on a replay. |
| The webhook is the final word | Reversals and some clearing events arrive only by webhook, because Visa requires approval. A client that approved over RHA must reverse on a rejected webhook. |
| Wallets are a certification project | Apple Pay certification runs in live production with a test house. It needs a project plan, owners and dates from day one. |
The digital asset arm of Fazz Financial Group, licensed by MAS as a Major Payment Institution. Cards are one of three pillars named for the October 2025 raise.
| Area | What is public | Integration read |
|---|---|---|
| Issuing model | Visa issuing member and BIN sponsor; issuer processing in house; virtual, physical and wearable cards; settlement in XUSD, XSGD, XIDR, USDC or prefunded fiat. | One team answers for scheme rules, processing and settlement. Tickets cross all three. |
| Two API surfaces | Card Management System (the client calls StraitsX, OAuth2 client credentials) and Remote Host Authorization plus webhooks (StraitsX calls the client). | Two auth schemes, two directions, two sets of error codes to explain. |
| Clients | RedotPay, OKX Card (Singapore), Pionex, Chocolate Finance, UPay, Tevau, Tappy and Tapeeze. | Mostly crypto platforms with Chinese-speaking teams across HK, Taiwan and Singapore. |
| Growth | Card transaction volume up 40x and cards issued up 83x from Q4 2024 to Q4 2025 (company figures via CoinDesk). | Onboarding throughput is the constraint. Self-serve pre-flight saves session time. |
| Mobile wallets | First Apple Pay in-app provisioning certification completed for Pionex (Jan 2026); more Apple Pay and Google Pay certifications planned in 2026. | A certification pipeline with external parties: Apple, Google, Visa, test houses. |
| Recent API changes | COF token auto-deactivation after two insufficient-balance declines (2026-09-03); customer_offboarded webhook (2026-09-11); RHA idempotency_key (2026-09-28). | Each release needs a client-facing migration note and a check in every open integration. |
Inferred from the docs, FAQs and release notes. Owner is where the fix sits once the evidence is in.
| Category | Typical message | First check | Fix owner |
|---|---|---|---|
| Credentials and access | "401 on every call" | Token from the right realm, sandbox creds on the sandbox host, token expiry, client id mapped to the issuing plan. | Integration (IdP setup) |
| Declines | "Cardholder was declined but we approved" | rejection_reason on the transaction webhook; RHA latency at that timestamp; card and token status. | Client, or StraitsX limits |
| RHA contract | "Your parser rejects our response" | Nested or flat balance shape; transaction_id echoed; error_code valid for the transaction type. | Client; docs if ambiguous |
| Webhooks | "Invalid signature", "missing reversal" | Raw-body HMAC; webhook secret distinct from API keys; retry schedule; dedupe on idempotency_key. | Client |
| Card lifecycle | "Cannot activate", "card pool empty" | One hour after creation, card_activation_ready, Tuesday print run, batch inventory. | Integration; Ops for inventory |
| Tokenization | "Apple Pay add card fails" | Card ACTIVE, card art and T&C metadata, 3DS phone for OTP, card_token_provisioning_failed reason. | Integration; Visa for VTS |
| Settlement and recon | "Spendable balance insufficient" | Settlement account balance, JIT funding recommendation, VIAA daily limit, Base I vs Base II mismatches. | Client finance; StraitsX finance |
| Disputes and fraud | "How do we raise a chargeback?" | Dispute guidelines, dispute_financial_advice events, AFD advisories. | Disputes team |
Card programmes pick an issuer on scheme access, settlement asset and time to launch. Integration quality decides whether they stay.
| Company | Model | Gap vs StraitsX | Integration angle |
|---|---|---|---|
| StraitsX | Visa member and BIN sponsor in Singapore, own processor, own MAS-regulated stablecoins. | Benchmark. | Client decides every auth through RHA: maximum control, maximum integration work. |
| Rain | Visa and Mastercard principal member; US$250M Series C (Jan 2026); expanding into APAC. | Much larger balance sheet; no local-currency stablecoin or MAS stablecoin status. | The rival that wins on dual network and scale. |
| Reap | Visa principal issuer in Hong Kong and Mexico; stablecoin-linked credit cards with Visa (Sept 2026). | No own regulated stablecoin yet. | Closest APAC rival, same Chinese-speaking client base. |
| Nium | Dual-network stablecoin card issuance behind one API (Mar 2026). | Stablecoin as a funding source, enterprise focus. | Wins large B2B programmes that want payouts too. |
| Bridge (Stripe) | Visa stablecoin cards through Stripe Issuing; Lead Bank. | US and LatAm first; thinner in Asia. | Best developer experience benchmark to match. |
| Thredd, Marqeta | Processors adding stablecoin settlement partners. | Client still needs a BIN sponsor and licence. | Programmes pair them with a sponsor; more parties per ticket. |
| Immersve | Mastercard principal member, self-custody USDC cards (NZ, AU, UK, EU). | Asia is future expansion. | Self-custody model with a different auth flow. |
| Kulipa | White-label stablecoin card layer; wound down 2026-07-29, about 20 programmes cut off. | Gone. | Displaced programmes need a fast, well-run migration. |
Encoding the docs into test cases forces a precise reading. Seven places where a client following the docs could build the wrong thing. Each is a small doc change or a line in a playbook.
| Finding | Evidence | Ticket it prevents |
|---|---|---|
| RHA approve body shape | The prose lists currency_code, ledger_balance, available_balance as top-level fields. The OpenAPI schema and example nest them under balances. | "Our approvals are being ignored." |
| RHA decline body shape | The prose lists error_code directly. The schema wraps it in an error object. | Declines read as internal errors. |
| Request example misses a required field | idempotency_key is required (effective 2026-09-28) and absent from the example, which carries acquirer_amount and acquirer_currency that the schema does not define. | Mock servers built from the example fail on the 28th. |
| Field name typo | F22 is named point_of_service_date_code. The page it links to is titled Point of Service Data Code and sits in the older v0.0.1 docs. | "The POS field is missing from your payload." |
| Webhook list vs enum | The prose lists card_status_transition; the event_type enum omits it and adds insufficient_balance and card_delivery, which the prose does not describe. | Strict enum validators drop real events. |
| Completion has no sign | On completion, amount is the absolute difference from the hold. Direction needs the hold, found by RRN, compared with F4. | Hotel checkouts booked in the wrong direction. |
| Retry window | Eleven webhook retries span about 6.5 hours after the first attempt. | Receivers down overnight lose reversals. |
Checked 24 September 2026 against docs.straitsx.com/v1-CARDS (Remote Host Authorization, Webhook Notification, Point of Service Data Code). The demo's suite accepts both readings where the docs conflict and reports which one it saw.
| JD duty | How I would do it | Detailed in |
|---|---|---|
| Guide clients from sandbox setup to production go-live | One tracker per programme with exit criteria per phase; a pre-flight run before every scheduled sandbox session so session time goes to edge cases. | §05, demo |
| Debug issues in sandbox and production | Start from the identifiers (transaction id, RRN, card opaque id), pull the webhook trail and RHA latency for that window, then reproduce with the exact payload. | §07 |
| Identity provider setup, access control, payment network portal configuration | Per-client OAuth clients scoped to their issuing plan, separate sandbox and production credentials, named owners, rotation dates, and a config record for each Visa portal change. | §05 |
| Payment network certification for mobile wallets | Run each Apple Pay and Google Pay certification as a project: agreements, test house slot, entitlement request, production test window, compliance review. | §06 |
| Documentation, playbooks, knowledge base | Playbooks per ticket type with the first three checks; the spec findings above turned into doc fixes and FAQ entries. | ★, §07 |
| First-line support in Slack and WhatsApp | Acknowledge fast, state what is being checked, reply in the client's language; technical strings stay in English so both sides can search them. | demo |
| Client feedback into Jira | Tickets with reproduction payload, identifiers, expected vs actual, client impact and count of affected programmes. | §07 |
| Generative AI and monitoring for troubleshooting | Dashboards on RHA latency and decline reasons per client; AI to cluster logs and draft replies from verified findings. | §08 |
| Work with Sales, Product, Engineering | Integration effort estimate at deal stage; release notes turned into per-client action lists. | §09 |
Each phase ends on evidence. The demo's Go-live tab holds the same checklist.
| Phase | Work | Exit evidence |
|---|---|---|
| Access | Sandbox OAuth client issued; dashboard users and roles; issuing plan and card product ids confirmed. | Client's server fetches a token and lists its card products. |
| Build | RHA endpoint with its own apiKey; webhook receiver verifying X-COP-Signature-256; reversal and recon handling; iframes for PAN and PIN unless PCI DSS certified. | Pre-flight suite clean with p95 under 1.5 s; signed webhook verified on the raw body. |
| Test | Client submits test cases; scheduled sandbox session with a funded test card. | Every case signed off; settlement account prefunded. |
| Production | Production credentials and URLs; first live low-value transaction; alerting on the client's RHA. | Transaction approved, webhook received, reconciled next day. |
| Hypercare | Daily check of decline reasons and latency for two weeks; shared channel with named escalation. | No unexplained CBS_IS_NOT_AVAILABLE or ERRORS_IN_SOFTWARE. |
External parties set the pace. The job is to have every dependency requested before it blocks.
| Track | Steps | What slips if ignored |
|---|---|---|
| Visa Token Service | Card art and T&C metadata per product; ID&V methods (call centre number, SMS OTP to the 3DS phone); card_token_passcode relay. | Provisioning fails on eligibility with no visible error to the cardholder. |
| Apple Pay | Agreements and test house (UL, Fime or Cell Software); in-app provisioning entitlement requested from Apple with the app's ID; certification in live production with capped test cards; compliance review. | The entitlement only works on distribution builds, so end-to-end tests happen in production. |
| Google Pay | Issuer Console profile, NDA, Click-To-Accept; push provisioning API access; client_customer_id and device_id on the StraitsX call. | Push provisioning is due within 6 months of launch under Google's terms. |
| Per programme | One tracker row per wallet per client, with the external owner and the next date. | Launch dates promised by Sales without a certification slot. |
From error code to root cause. The demo's Decode and Error lookup tabs run the first checks.
| Symptom | Checks, in order | What the client hears | Route |
|---|---|---|---|
CBS_IS_NOT_AVAILABLE | RHA latency and status at the timestamp; client deploys or scaling events; TLS and DNS on their endpoint. | The exact window, the latency seen, and the 6 s budget. | Client engineering |
ERRORS_IN_SOFTWARE | Client returned CARD0000 or CARD0005; apiKey rotated on one side; maintenance mode. | Which code they sent and how often. | Client; StraitsX if maintenance |
| Signature mismatch | Raw body or re-serialised JSON; webhook secret vs API key; prefix sha256= handled. | Verify raw bytes before parsing. | Client |
| Balance drift | Idempotency on replays; completions booked by direction; reversals and reconciliation_manual_adjustment applied. | The transaction list that explains the difference. | Client finance |
| Token provisioning failed | Card status; card art and T&C present; 3DS phone enrolled; failure reason on the webhook. | The missing prerequisite. | Integration; Visa if VTS |
XFC401001 | Realm and host pairing; expiry; client id to issuing plan mapping. | The corrected host or credential. | Integration (IdP) |
INSUFFICIENT_SPENDABLE_BALANCE | Settlement account balance; JIT funding recommendation; weekend coverage. | Top-up amount and cut-off. | Client finance |
VIAA_LIMIT_EXCEEDED | Issuing group daily Visa limit; volume trend. | Limit reached and the collateral path. | StraitsX account owner |
Deterministic checks produce the facts; AI writes from them. Replies stay fast and auditable.
| Workflow | How it works | Guardrail |
|---|---|---|
| Per-client health | DataDog or Grafana panels: RHA p95, timeouts, decline reasons, webhook delivery failures, split by client. | Alert on change against each client's own baseline. |
| Log triage | AI clusters error logs by signature and links each cluster to a playbook. | Counts from the log store; the model names clusters. |
| Client replies | Draft from verified findings in the client's language; technical identifiers kept verbatim. | Human sends; no invented ids or dates. |
| Docs drift | Diff schemas, enums and prose on each docs release; the ★ findings are the first output. | Output is a ticket to the docs owner. |
| Release fan-out | Turn each release note into a per-client checklist, e.g. who handles idempotency_key by 2026-09-28. | Tracked to closure per client. |
Built from the public job posting (2026), all 108 public StraitsX Card Issuing doc pages (read 2026-09-24), StraitsX blog posts and press coverage. Company figures are labelled as company figures. The demo is my own tool: its reference client host is a sample implementation of the documented contract, and all ids in it are invented. Unsolicited interview homework; happy to walk through any section.
Card docs: introduction · Remote Host Authorization
RHA: error codes · FAQs
Webhooks: notification · rejection reasons
Tokens: Visa card tokenization · release notes
Issuing model: card issuance · OKX Card
Apple Pay: Pionex certification · enabling Apple Pay
Growth: CoinDesk, Mar 2026 · Funding: Fintech Singapore
Google Pay: issuer onboarding
Independent integration homework for the StraitsX Integration Engineer, Card Issuing role · 2026 · edwardtay.com