[{"data":1,"prerenderedAt":189},["ShallowReactive",2],{"content-\u002Fprompts\u002Fintegrate-blindpay-wallet":3,"prompts-category-integrations":119},{"id":4,"title":5,"author":6,"body":7,"categories":6,"category":101,"categoryType":6,"date":102,"description":103,"extension":104,"faq":6,"howto":6,"isBlog":105,"isChangelog":105,"meta":106,"navigation":107,"path":108,"pillar":105,"products":109,"rawbody":115,"seo":116,"stem":117,"thumbnail":6,"updated":6,"__hash__":118},"content\u002Fprompts\u002Fintegrate-blindpay-wallet.md","Integrate the BlindPay wallet",null,{"type":8,"value":9,"toc":95},"minimark",[10,14,19,30,34,51,55],[11,12,13],"p",{},"Paste this prompt into your coding agent to build on the BlindPay wallet: BlindPay generates the address and holds the keys, so your customers get a balance inside your product with no browser wallet and no transaction signing.",[15,16,18],"h2",{"id":17},"prompt","Prompt",[20,21,27],"pre",{"className":22,"code":24,"language":25,"meta":26},[23],"language-text","You are integrating the BlindPay wallet (the managed, BlindPay-custodied wallet) into my application: BlindPay creates and custodies a wallet per customer, and I move money through it with plain API calls, never with private keys or signatures on my side.\n\nBefore writing code, read these sources and follow them over any prior knowledge:\n- https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fllms.txt (read the managed wallets, payins, payouts, send, and webhooks pages)\n- The OpenAPI spec: curl https:\u002F\u002Fapi.blindpay.com\u002Fdoc\n\nBuild the flow:\n1. Prerequisites: an approved customer (kyc_status \"approved\"). Managed wallets are in beta; support only the chains the docs list (Ethereum, Base, Polygon, Arbitrum, Solana) with USDC\u002FUSDT, and USDB on development testnets. Stellar and Tron are not supported for managed wallets; if I need those, fall back to blockchain wallets instead.\n2. Create the wallet: POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers\u002F{customer_id}\u002Fwallets with network, name, and my database ID as external_id. BlindPay generates the address server-side. Persist both the id (bl_) and the address against my user record: payin quotes reference the id, payouts reference the address. A customer can hold up to 10 wallets; enforce that in my schema. Never confuse bl_ (managed wallet) with bw_ (blockchain wallet) when passing IDs into quotes or payouts.\n3. Show the balance: GET \u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers\u002F{customer_id}\u002Fwallets\u002F{wallet_id}\u002Fbalance. Treat this endpoint as the source of truth for available funds and check it before quoting any outbound movement.\n4. Money in, two paths:\n   a. Fiat payin: POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Fpayin-quotes with wallet_id (not blockchain_wallet_id), then POST \u002Fpayins\u002Fevm with the resulting payin_quote_id. Stablecoins settle into the wallet; confirm with payin.complete and wallet.inbound webhooks.\n   b. Direct stablecoin deposit: share the wallet address; any USDC\u002FUSDT transfer on the matching network credits it and fires wallet.inbound. Warn users that deposits on the wrong chain are lost.\n5. Money out, two paths:\n   a. Fiat payout: POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Fquotes for a payout quote, then POST \u002Fpayouts\u002Fevm with quote_id and the managed wallet's address as sender_wallet_address before expires_at. Because BlindPay custodies the wallet there is no ERC-20 approve and no signature step; the payout is a single call.\n   b. Stablecoin transfer: POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Ftransfer-quotes then POST \u002Ftransfers to move funds to another wallet or external address. The transfer quote expires in 15 seconds, the shortest of any BlindPay quote, so quote and execute in one server-side sequence. Only USDC crosses chains (Circle CCTP v2 between Ethereum, Polygon, Base, Arbitrum); everything else needs the same network on both sides.\n6. Drive state from Svix-verified webhooks (svix-id, svix-timestamp, svix-signature against the raw body): wallet.new on creation, wallet.inbound on deposits, payin.new\u002Fcomplete, payout.new\u002Fupdate\u002Fcomplete, transfer.new\u002Fcomplete. Reconcile every event back to my user via the bl_ ID or external_id.\n7. Handle the unit mismatch explicitly: wallet.inbound reports amount scaled by 100 (100 means $1.00) while the balance endpoint reports the raw amount. Normalize both into one internal representation with a documented conversion, and never compare them directly.\n8. Test end to end on a development instance: KYC auto-approves, USDB works on every dev testnet, and payout sentinel amounts verify all outcomes ($666.00 forces a failed payout, $777.00 forces a refunded one).\n\nConstraints:\n- API keys stay server-side; never expose instance or customer IDs in client code paths that don't need them.\n- Amounts are integers in minor units everywhere; never use floating point for money.\n- Idempotency on money movement: key payins, payouts, and transfers on my own transaction ID and check for an existing record before creating.\n- wallet.inbound only fires for USDC and USDT; don't rely on it for other tokens.\n\nDeliverables: wallet provisioning service with the bl_\u002Faddress persistence, balance display wired to the balance endpoint, payin-to-wallet and payout-from-wallet flows, the transfer path with the 15-second quote handled, webhook handlers with unit normalization, and a passing end-to-end test on the development instance covering deposit, payout, failed, and refunded cases.\n","text","",[28,29,24],"code",{"__ignoreMap":26},[15,31,33],{"id":32},"how-to-use","How to use",[35,36,37,41,44],"ol",{},[38,39,40],"li",{},"Paste the prompt with your stack details and which chains you actually need.",[38,42,43],{},"Decide the wallet-per-customer model up front: one balance wallet per user is the common case; the 10-wallet cap matters only for multi-currency or multi-chain designs.",[38,45,46,47,50],{},"Run the sentinel-amount payout tests on a development instance before touching production; the unit mismatch between ",[28,48,49],{},"wallet.inbound"," and the balance endpoint is the most common reconciliation bug.",[15,52,54],{"id":53},"related-docs","Related docs",[56,57,58,67,74,81,88],"ul",{},[38,59,60],{},[61,62,66],"a",{"href":63,"rel":64},"https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fwallets",[65],"nofollow","Managed wallets",[38,68,69],{},[61,70,73],{"href":71,"rel":72},"https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fpayin-managed-wallet",[65],"Payin with managed wallet",[38,75,76],{},[61,77,80],{"href":78,"rel":79},"https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fpayout-managed-wallet",[65],"Payout with managed wallet",[38,82,83],{},[61,84,87],{"href":85,"rel":86},"https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fsend",[65],"Send",[38,89,90],{},[61,91,94],{"href":92,"rel":93},"https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fstore",[65],"Store",{"title":26,"searchDepth":96,"depth":96,"links":97},2,[98,99,100],{"id":17,"depth":96,"text":18},{"id":32,"depth":96,"text":33},{"id":53,"depth":96,"text":54},"integrations","2026-08-28","Hold customer stablecoin balances in BlindPay-custodied wallets: create the wallet, collect payins into it, pay out from it with no signing step.","md",false,{},true,"\u002Fprompts\u002Fintegrate-blindpay-wallet",[110,111,112,113,114],"payins","payouts","quotes","compliance","webhooks","---\ntitle: \"Integrate the BlindPay wallet\"\ndescription: \"Hold customer stablecoin balances in BlindPay-custodied wallets: create the wallet, collect payins into it, pay out from it with no signing step.\"\ndate: \"2026-08-28\"\ncategory: \"integrations\"\nproducts: [\"payins\", \"payouts\", \"quotes\", \"compliance\", \"webhooks\"]\n---\n\nPaste this prompt into your coding agent to build on the BlindPay wallet: BlindPay generates the address and holds the keys, so your customers get a balance inside your product with no browser wallet and no transaction signing.\n\n## Prompt\n\n```text\nYou are integrating the BlindPay wallet (the managed, BlindPay-custodied wallet) into my application: BlindPay creates and custodies a wallet per customer, and I move money through it with plain API calls, never with private keys or signatures on my side.\n\nBefore writing code, read these sources and follow them over any prior knowledge:\n- https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fllms.txt (read the managed wallets, payins, payouts, send, and webhooks pages)\n- The OpenAPI spec: curl https:\u002F\u002Fapi.blindpay.com\u002Fdoc\n\nBuild the flow:\n1. Prerequisites: an approved customer (kyc_status \"approved\"). Managed wallets are in beta; support only the chains the docs list (Ethereum, Base, Polygon, Arbitrum, Solana) with USDC\u002FUSDT, and USDB on development testnets. Stellar and Tron are not supported for managed wallets; if I need those, fall back to blockchain wallets instead.\n2. Create the wallet: POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers\u002F{customer_id}\u002Fwallets with network, name, and my database ID as external_id. BlindPay generates the address server-side. Persist both the id (bl_) and the address against my user record: payin quotes reference the id, payouts reference the address. A customer can hold up to 10 wallets; enforce that in my schema. Never confuse bl_ (managed wallet) with bw_ (blockchain wallet) when passing IDs into quotes or payouts.\n3. Show the balance: GET \u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers\u002F{customer_id}\u002Fwallets\u002F{wallet_id}\u002Fbalance. Treat this endpoint as the source of truth for available funds and check it before quoting any outbound movement.\n4. Money in, two paths:\n   a. Fiat payin: POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Fpayin-quotes with wallet_id (not blockchain_wallet_id), then POST \u002Fpayins\u002Fevm with the resulting payin_quote_id. Stablecoins settle into the wallet; confirm with payin.complete and wallet.inbound webhooks.\n   b. Direct stablecoin deposit: share the wallet address; any USDC\u002FUSDT transfer on the matching network credits it and fires wallet.inbound. Warn users that deposits on the wrong chain are lost.\n5. Money out, two paths:\n   a. Fiat payout: POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Fquotes for a payout quote, then POST \u002Fpayouts\u002Fevm with quote_id and the managed wallet's address as sender_wallet_address before expires_at. Because BlindPay custodies the wallet there is no ERC-20 approve and no signature step; the payout is a single call.\n   b. Stablecoin transfer: POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Ftransfer-quotes then POST \u002Ftransfers to move funds to another wallet or external address. The transfer quote expires in 15 seconds, the shortest of any BlindPay quote, so quote and execute in one server-side sequence. Only USDC crosses chains (Circle CCTP v2 between Ethereum, Polygon, Base, Arbitrum); everything else needs the same network on both sides.\n6. Drive state from Svix-verified webhooks (svix-id, svix-timestamp, svix-signature against the raw body): wallet.new on creation, wallet.inbound on deposits, payin.new\u002Fcomplete, payout.new\u002Fupdate\u002Fcomplete, transfer.new\u002Fcomplete. Reconcile every event back to my user via the bl_ ID or external_id.\n7. Handle the unit mismatch explicitly: wallet.inbound reports amount scaled by 100 (100 means $1.00) while the balance endpoint reports the raw amount. Normalize both into one internal representation with a documented conversion, and never compare them directly.\n8. Test end to end on a development instance: KYC auto-approves, USDB works on every dev testnet, and payout sentinel amounts verify all outcomes ($666.00 forces a failed payout, $777.00 forces a refunded one).\n\nConstraints:\n- API keys stay server-side; never expose instance or customer IDs in client code paths that don't need them.\n- Amounts are integers in minor units everywhere; never use floating point for money.\n- Idempotency on money movement: key payins, payouts, and transfers on my own transaction ID and check for an existing record before creating.\n- wallet.inbound only fires for USDC and USDT; don't rely on it for other tokens.\n\nDeliverables: wallet provisioning service with the bl_\u002Faddress persistence, balance display wired to the balance endpoint, payin-to-wallet and payout-from-wallet flows, the transfer path with the 15-second quote handled, webhook handlers with unit normalization, and a passing end-to-end test on the development instance covering deposit, payout, failed, and refunded cases.\n```\n\n## How to use\n\n1. Paste the prompt with your stack details and which chains you actually need.\n2. Decide the wallet-per-customer model up front: one balance wallet per user is the common case; the 10-wallet cap matters only for multi-currency or multi-chain designs.\n3. Run the sentinel-amount payout tests on a development instance before touching production; the unit mismatch between `wallet.inbound` and the balance endpoint is the most common reconciliation bug.\n\n## Related docs\n\n- [Managed wallets](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fwallets)\n- [Payin with managed wallet](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fpayin-managed-wallet)\n- [Payout with managed wallet](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fpayout-managed-wallet)\n- [Send](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fsend)\n- [Store](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fstore)\n",{"title":5,"description":103},"prompts\u002Fintegrate-blindpay-wallet","ljvbdZ7JFMjsDGiawYfn18r1pIn0vUFIKZiA-AtThU8",[120,124,128,132,136,140,144,148,152,156,160,164,168,172,176,177,181,185],{"path":121,"title":122,"description":123},"\u002Fprompts\u002Fbuild-contractor-payouts","Build a global contractor payout product","Compose onboarding, bank accounts, quotes, payouts, and reconciliation into a complete pay-your-contractors feature across Pix, SPEI, SEPA, and ACH.",{"path":125,"title":126,"description":127},"\u002Fprompts\u002Fconnect-ai-agent-mcp","Connect an AI agent with the MCP server","Wire Claude, Cursor, or any MCP-compatible host to the BlindPay API with the official MCP server and agent skills, with guardrails for money movement.",{"path":129,"title":130,"description":131},"\u002Fprompts\u002Fintegrate-external-wallet-payouts","Fund payouts from external wallets","Let customers pay out from their own EVM, Solana, or Stellar wallets: signed-message registration plus the on-chain authorization step per chain.",{"path":133,"title":134,"description":135},"\u002Fprompts\u002Fintegrate-circle-wallets","Integrate Circle wallets with BlindPay","Fund BlindPay payouts from Circle developer-controlled wallets: sign the registration challenge and the ERC-20 approve through Circle's API instead of a browser wallet.",{"path":137,"title":138,"description":139},"\u002Fprompts\u002Fintegrate-dfns","Integrate Dfns with BlindPay","Fund BlindPay stablecoin payouts from Dfns MPC wallets: sign the registration challenge and the ERC-20 approve through Dfns's User Action Signature flow.",{"path":141,"title":142,"description":143},"\u002Fprompts\u002Fintegrate-fireblocks","Integrate Fireblocks with BlindPay","Fund BlindPay stablecoin payouts from Fireblocks vault accounts: MPC-signed wallet registration and the ERC-20 approve through Fireblocks' transactions API.",{"path":145,"title":146,"description":147},"\u002Fprompts\u002Fintegrate-privy","Integrate Privy with BlindPay","Fund BlindPay stablecoin payouts from Privy Server Wallets: sign the registration challenge and the ERC-20 approve through Privy's wallet RPC endpoint.",{"path":149,"title":150,"description":151},"\u002Fprompts\u002Fintegrate-virtual-accounts","Integrate US virtual accounts","Give each customer a named US bank account with ACH, RTP, wire, and SWIFT details that settles automatically to USDC or USDT in their wallet.",{"path":153,"title":154,"description":155},"\u002Fprompts\u002Fintegrate-utila","Integrate Utila with BlindPay","Fund BlindPay payouts from Utila MPC vaults: sign the wallet-registration challenge and the ERC-20 approve through Utila's service-account API, with async transaction confirmation handled.",{"path":157,"title":158,"description":159},"\u002Fprompts\u002Fintegrate-customer-onboarding","Integrate customer onboarding with KYC and KYB","Build the full onboarding pipeline: terms of service, individual and business customers, document uploads, RFI handling, and status webhooks.",{"path":161,"title":162,"description":163},"\u002Fprompts\u002Fintegrate-offramp-wallets","Integrate offramp wallets for auto-conversion","Give each bank account a dedicated crypto deposit address: stablecoins sent to it convert and pay out to the linked bank account automatically.",{"path":165,"title":166,"description":167},"\u002Fprompts\u002Fintegrate-payins","Integrate payins from bank transfers to stablecoins","Accept Pix, ACH, wire, SPEI, and other local bank transfers and settle them as USDC or USDT in a wallet, with quotes, payment instructions, and webhooks.",{"path":169,"title":170,"description":171},"\u002Fprompts\u002Fintegrate-quotes-fx","Integrate quotes and FX handling","Handle payin, payout, and transfer quotes correctly: expiry windows, currency_type conventions, fees, and displaying rates to users.",{"path":173,"title":174,"description":175},"\u002Fprompts\u002Fintegrate-stablecoin-payouts","Integrate stablecoin payouts end to end","Build a complete stablecoin to fiat payout flow: customer onboarding, bank accounts, quotes, and payout execution over Pix, ACH, SPEI, SEPA, and more.",{"path":108,"title":5,"description":103},{"path":178,"title":179,"description":180},"\u002Fprompts\u002Fintegrate-wallet-transfers","Integrate wallet transfers and cross-chain USDC","Move stablecoins from managed wallets to any address with transfer quotes, including cross-chain USDC over Circle CCTP v2.",{"path":182,"title":183,"description":184},"\u002Fprompts\u002Fintegrate-webhooks","Integrate webhooks end to end","Register endpoints, verify Svix signatures correctly, deduplicate retries, and drive payment state from the full BlindPay event catalog.",{"path":186,"title":187,"description":188},"\u002Fprompts\u002Fintegrate-payables","Pay boletos and Brazilian bills with payables","Register boletos, arrecadacao slips, and PIX codes as payables and settle them from stablecoins through the quote-and-execute flow.",1787944261087]