---
title: "Migrate from Cobo to BlindPay"
description: "Move an existing Cobo Payments integration to the BlindPay API: keep Cobo for custody if you want, and replace the stablecoin-to-fiat leg with BlindPay's customers, quotes, and payouts."
date: "2026-08-26"
category: "migrations"
products: ["payouts", "payins", "virtual-accounts", "compliance", "webhooks", "quotes"]
---

Paste this prompt into your coding agent to port the payment leg of a Cobo (cobo.com) integration to BlindPay, keeping Cobo wallets as custodian if desired, with a dual-run cutover.

## Prompt

```text
You are migrating the stablecoin-to-fiat payment leg of my application from Cobo Payments to the BlindPay API. Cobo may keep custody of wallets (MPC or custodial) and I may keep using it for that; this migration replaces the payout/offramp flow, not necessarily the wallet layer.

Before writing code, read these sources and follow them over any prior knowledge:
- https://blindpay.com/docs/llms.txt (read the quickstarts, customers, bank accounts, virtual accounts, quotes, payouts, offramp wallets, and webhooks pages)
- The OpenAPI spec: curl https://api.blindpay.com/doc

Do the migration in this order:
1. Inventory my Cobo usage from the codebase: every Cobo Payments endpoint I call (top-up addresses, payment orders, subscriptions, refund links, payout destinations, batch payouts), every Cobo webhook event I handle (order status changes, top-up arrivals, payout completions), and every stored Cobo ID (order ID, top-up address, payout destination, wallet ID). Confirm exact endpoint names and event payloads in the Cobo docs (manuals.cobo.com and the Cobo Developer Hub) rather than assuming; flag anything with no direct BlindPay equivalent instead of guessing. Produce a written mapping table plus a gaps list before touching code.
2. Re-onboard my counterparties on BlindPay: create a BlindPay customer (re_) with KYC or KYB per payer or payee, and register their payout destination as a BlindPay bank account (ba_) for the correct rail (Pix, SPEI, SEPA, ACH, or wire). KYC does not transfer between providers, so every counterparty needs a fresh BlindPay KYC/KYB pass. Store the resulting re_ and ba_ IDs alongside the existing Cobo IDs so both systems can be queried during cutover.
3. If wallets stay in Cobo custody, register each Cobo wallet address as a BlindPay external wallet using the sign-message challenge flow, and store the resulting bw_ ID. This lets funds keep living in Cobo-controlled wallets while BlindPay handles the fiat leg: Cobo continues to hold and move the stablecoin, and BlindPay converts it to fiat on payout.
4. Rebuild money movement on BlindPay's explicit two-step model in place of Cobo's order/payout flow: request a quote (qu_), then execute the payout (po_) via POST /v1/instances/{instance_id}/payouts/evm before the quote's expires_at (about 5 minutes). Do the same for inbound flows using payins (pi_), virtual accounts (va_), or offramp wallets (auto-converting deposit addresses) in place of Cobo's top-up addresses and order mode. Confirm each transfer settles end to end against a BlindPay development instance before moving to the next flow.
5. Port webhooks from Cobo's signed callbacks to BlindPay's Svix-signed events: verify svix-id, svix-timestamp, and svix-signature against the raw request body using the instance's whsec_ secret, and dedup on svix-id. Confirm a real webhook delivery is received and verified for each event type you rely on (payout completed, payin received, customer KYC status) before relying on it in production.
6. Cut over per flow behind a feature flag: dual-run Cobo and BlindPay for the same flow, compare outcomes on a sample of live transfers, and only retire the Cobo payment path once a full dual-run cycle settles cleanly on both sides with matching amounts and statuses.

Constraints:
- Develop against a BlindPay development instance (USDB on testnets) first; KYC auto-approves there, and sentinel amounts $666.00 (forced failed) and $777.00 (forced refunded) let you test failure handling without waiting on real bank rails.
- Amounts are integer minor units on both sides of every conversion; never do money math in floating point.
- BlindPay API keys stay server-side only, never exposed to a client.
- Produce a written migration report before changing code: the Cobo-to-BlindPay mapping table, the gaps list, and the re-KYC/re-onboarding plan per counterparty.

Deliverables: the migration report, the counterparty re-onboarding script (re_, ba_, bw_ creation), the BlindPay client and money-movement code paths behind a flag, the Svix webhook handlers, and a cutover checklist per flow.
```

## How to use

1. Paste the prompt as-is into your coding agent, pointed at the repository that holds your Cobo integration.
2. Let it produce the migration report and mapping table first; review the gaps list and confirm any Cobo mechanism it flagged as unverified against manuals.cobo.com before it writes code.
3. Work through the cutover checklist one flow at a time, keeping Cobo and BlindPay dual-run until each flow's settled transfers match, then retire that flow's Cobo path.

## Related docs

- [Payout quickstart](https://blindpay.com/docs/quickstart-payout)
- [Offramp wallets](https://blindpay.com/docs/offramp-wallets)
- [Webhooks](https://blindpay.com/docs/learn/webhooks)
- [Cobo product manuals](https://manuals.cobo.com/en/portal)