---
title: "Migrate from Turnkey to BlindPay"
description: "Keep Turnkey for wallets and signing, and move the stablecoin-to-fiat offramp leg of a Turnkey-based product to BlindPay: map payout accounts, quotes, and webhooks."
date: "2026-08-26"
category: "migrations"
products: ["payouts", "quotes", "compliance", "webhooks"]
---

Paste this prompt into your coding agent to move the stablecoin-to-fiat offramp leg of a Turnkey (docs.turnkey.com) integration to BlindPay, keeping Turnkey as the wallet and signing layer.

## Prompt

```text
You are migrating my application's stablecoin-to-fiat offramp and payout leg from whatever I bolted onto Turnkey (docs.turnkey.com) to BlindPay. Turnkey stays in place as the wallet infrastructure, policy engine, and signing API; my product's stablecoins keep living in Turnkey wallets. This migration targets only the fiat payout surface, not custody or signing.

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

Do the migration in this order:
1. Inventory my Turnkey usage from the codebase: every sign transaction and sign raw payload activity tied to a payout flow, the wallet accounts and addresses those activities sign from, the policies gating them (consensus and condition rules in the policy engine), any activity webhooks I consume, and whatever offramp or fiat rail I built on top of a signed transaction today (a third-party payout API, a manual process, a liquidation address). Confirm any Turnkey mechanism I have not explicitly listed against the Turnkey docs before relying on it. Flag anything with no direct BlindPay equivalent instead of guessing.
2. Onboard payees on BlindPay: create customer, KYC/KYB via document upload, add rail-specific bank accounts (Pix, SPEI, SEPA, ACH, wire), driven by webhooks. Store the resulting re_ and ba_ IDs, and produce a written onboarding report before touching money movement.
3. Connect the Turnkey wallet to BlindPay without moving funds: register the Turnkey wallet address with BlindPay's external-wallet flow (sign-message challenge signed by the Turnkey wallet, resulting bw_ ID). Store the bw_ ID alongside the Turnkey wallet account it maps to.
4. Rebuild the payout leg on BlindPay's explicit two-step model: request a quote (qu_), then execute the payout (po_) via POST /v1/instances/{instance_id}/payouts/evm before expires_at (about 5 minutes), sourcing funds from the Turnkey-controlled wallet you registered in step 3. Store qu_ and po_ IDs next to the legacy payout records they replace.
5. 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. Keep Turnkey's own activity webhooks, if I use them, unchanged since Turnkey keeps signing.
6. Cut over per payout corridor behind a feature flag: dual-run with new payouts on BlindPay while the old offramp path handles in-flight items, keep both webhook handlers live during the window, and retire the old offramp path only 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 onboarding plan.

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

## How to use

1. Point the agent at your codebase so it inventories real Turnkey sign transaction activity and policy config rather than assuming.
2. Review the migration report, especially the external-wallet registration step, since it is the only point where Turnkey and BlindPay actually connect.
3. Dual-run at least one full settlement cycle per corridor, including the sentinel failure and refund cases, before retiring the old offramp 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 verification](https://blindpay.com/docs/learn/webhooks-verification)
- [Turnkey policy engine overview](https://docs.turnkey.com/concepts/policies/overview)