---
title: "Migrate from Fireblocks to BlindPay"
description: "Move the stablecoin-to-fiat payout leg of a Fireblocks integration to BlindPay: map payout instruction sets, fiat accounts, and webhooks while Fireblocks stays as custodian."
date: "2026-08-26"
category: "migrations"
products: ["payouts", "quotes", "compliance", "webhooks"]
---

Paste this prompt into your coding agent to move the fiat payout leg of a Fireblocks (developers.fireblocks.com) integration to BlindPay, keeping Fireblocks for custody and signing where you want it.

## Prompt

```text
You are migrating my application's stablecoin-to-fiat payout leg from Fireblocks (developers.fireblocks.com) to BlindPay. Fireblocks can stay in place for custody and transaction signing (vault accounts, transactions, whitelisted addresses); this migration targets only the fiat payout and offramp surface.

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, payout quotes, payouts, and webhooks pages)
- The OpenAPI spec: curl https://api.blindpay.com/doc

Do the migration in this order:
1. Inventory my Fireblocks usage from the codebase: every Payments Engine call (payout instruction set creation, payout execution), connected fiat accounts, travel rule policy config, and webhook subscriptions (Fireblocks-Signature or Fireblocks-Webhook-Signature headers), plus every stored Fireblocks ID (payment accounts, payee accounts, payout instruction sets). Derive the concept mapping from what we actually use, roughly: Fireblocks payee fiat accounts map to BlindPay customers (re_) with KYC/KYB and bank accounts (ba_); a Fireblocks payout instruction set maps to a BlindPay quote (qu_) followed by an executed payout (po_); Fireblocks vault accounts, transactions, and whitelisted addresses have no BlindPay equivalent and stay on Fireblocks as the custody and signing layer. Flag anything with no direct equivalent instead of guessing, and confirm any Fireblocks mechanism I have not explicitly listed against the Fireblocks docs before relying on it.
2. Re-onboard payees on BlindPay: create customer, KYC/KYB via document upload, add rail-specific bank accounts (Pix, SPEI, SEPA, ACH, wire), driven by webhooks. KYC does not transfer between providers, so plan for re-verification and sequence it before the cutover so approved payees are ready when we switch. Store the resulting re_ and ba_ IDs next to the legacy Fireblocks payee account IDs.
3. Rebuild the payout leg on BlindPay's explicit two-step model: request a quote, then execute the payout before expires_at (about 5 minutes), replacing the Fireblocks payout instruction set creation-then-execution flow. If funds keep custody in Fireblocks vault accounts, register the Fireblocks-controlled wallet with BlindPay through the external-wallet sign-message challenge (bw_ ID) so BlindPay can source funds from it. Store qu_, po_, and bw_ IDs alongside the legacy Fireblocks IDs during the transition.
4. Port webhooks to BlindPay's Svix-signed events (customer.*, payout.*, wallet.inbound), verifying svix-id, svix-timestamp, and svix-signature against the raw request body with whsec_ and deduping on svix-id, replacing the Fireblocks-Signature RSA verification. Confirm every Fireblocks event type we currently consume has a BlindPay equivalent before cutting a flow over.
5. Cut over per payout corridor behind a feature flag: dual-run with new payouts on BlindPay while Fireblocks payout instruction sets handle in-flight items, keep both webhook handlers live during the window, and only retire the Fireblocks payout path once a full dual-run settlement cycle has completed and been verified against the corridor's expected outcomes.

Constraints:
- Develop against a BlindPay development instance (USDB on testnets, KYC auto-approves) first, and exercise the $666.00 forced-failed and $777.00 forced-refunded sentinel amounts before touching production traffic.
- Amounts are integer minor units; API keys stay server-side.
- Produce a written migration report before changing code: the mapping table, gaps, and the re-KYC plan.

Deliverables: the migration report, re-onboarding script, the BlindPay client and quote/payout code paths behind a flag, the external-wallet registration flow if custody stays on Fireblocks, webhook handlers, and a cutover checklist.
```

## How to use

1. Point the agent at your codebase so it inventories real Fireblocks Payments Engine usage rather than assuming.
2. Review the migration report, especially which Fireblocks pieces stay (custody, signing) versus move (payouts, webhooks), before approving code changes.
3. Dual-run at least one full settlement cycle per corridor, including the sentinel failure and refund cases, before retiring the Fireblocks payout path.

## Related docs

- [Introduction](https://blindpay.com/docs/introduction)
- [Customers](https://blindpay.com/docs/learn/customers)
- [Payout quotes](https://blindpay.com/docs/payout-quotes)
- [Webhooks](https://blindpay.com/docs/learn/webhooks)