[{"data":1,"prerenderedAt":187},["ShallowReactive",2],{"content-\u002Fprompts\u002Fintegrate-invoice-payables":3,"prompts-category-integrations":113},{"id":4,"title":5,"authors":6,"body":7,"categories":6,"category":97,"categoryType":6,"contributors":6,"date":98,"description":99,"extension":100,"faq":6,"howto":6,"isBlog":101,"isChangelog":101,"meta":102,"navigation":103,"path":104,"pillar":101,"products":105,"rawbody":109,"seo":110,"stem":111,"thumbnail":6,"updated":6,"__hash__":112},"content\u002Fprompts\u002Fintegrate-invoice-payables.md","Pay US vendor invoices with payables",null,{"type":8,"value":9,"toc":91},"minimark",[10,14,19,30,34,47,51],[11,12,13],"p",{},"Paste this prompt into your coding agent to build accounts payable on stablecoins: your users upload a vendor invoice, BlindPay reads it, and pays the vendor's US bank account over ACH or wire.",[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 BlindPay invoice payables into my application: registering US supplier invoices (line items plus the vendor's ACH or wire bank details) and paying them from stablecoins.\n\nBefore writing code, read these sources and follow them over any prior knowledge:\n- https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fllms.txt (read the payables, invoice payables, bank accounts, payout quotes, payouts, and webhooks pages)\n- The OpenAPI spec: curl https:\u002F\u002Fapi.blindpay.com\u002Fdoc\n\nBuild the flow:\n1. Prerequisites: an approved customer (KYC\u002FKYB) and a funded wallet, managed or external. Reuse my existing onboarding if present.\n2. Upload the invoice: POST \u002Fv1\u002Fupload with bucket `documents`, keep the returned file_url. Then POST \u002Fv1\u002Fupload\u002Fextract?instance_id={instance_id} with the same file to prefill amount, currency, due_date, invoice_number, the `to` party, line_items, and payment_options. Every extracted field is nullable and nothing is guessed, so render the result as an editable form and require the user to confirm the bank fields against the document before submitting.\n3. Register the invoice: POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Fpayables with currency USD, from\u002Fto parties, line_items (name, quantity, unit price in cents), optional note, discount, and taxes, the vendor's bank_account (type `ach` or `wire`, same shape as POST \u002Fcustomers\u002F{customer_id}\u002Fbank-accounts, with beneficiary_name, routing_number, account_number, account_type, account_class, business_industry as a NAICS code whenever account_class is `business`, recipient_relationship, and address), plus document_file set to the file_url from step 2. Pick the ACH payment option when the invoice prints one; it is the cheapest rail. Persist the returned pb_ ID and the derived amount (line item sum plus taxes minus discount).\n4. Quote against the payable: POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Fquotes with payable_id instead of bank_account_id, plus network and token; do not send request_amount or currency_type. Execute with POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Fpayouts\u002Fevm before the quote's expires_at. Show the user the quote's fees and total before executing.\n5. Track the bill through payable.new, payable.update, and payable.complete, and the payment attempt through payout.new, payout.update, and payout.complete, all with Svix signature verification. Correlate the two streams through payable_id and payout_id, and never count a payout.complete and its payable.complete as two payments. The payable stays `processing` while the payout is held for manual review; compliance holds, releases, and failure reasons arrive only on the payout events.\n6. Handle the failure paths explicitly: a failed or refunded attempt returns the payable to `draft` with last_attempt_status set, so quote the same payable again instead of registering it twice; bills under the 10.00 USD minimum are rejected at registration with LIMITS_AMOUNT_OUT_OF_RANGE; a bank_account that fails validation is rejected with payable_bank_account_invalid and the failing field in errors; and a quote that expired must be re-quoted and re-confirmed with the user.\n7. Let the user delete a draft: DELETE \u002Fv1\u002Finstances\u002F{instance_id}\u002Fpayables\u002F{payable_id} works only while no payout exists for it (payable_not_cancelable otherwise).\n\nConstraints:\n- Amounts are integers in cents; line_items[].price is the unit price, so 150000 is $1,500.00. API keys stay server-side.\n- The bank account created for an invoice belongs to the payable: it is not listed with the customer's bank accounts and cannot be quoted on its own, so never reuse it for regular payouts.\n- Invoice payables are USD only and settle on EVM networks. Boleto and PIX bills use a different registration shape; do not mix them into this flow.\n- POST \u002Fupload\u002Fextract is limited to 60 requests per minute per instance and returns a fixed sample on development instances; code the extract-then-confirm step so a null field is a normal case, not an error. The NAICS code is never printed on an invoice, so the form must ask for it.\n- Validate the routing number client-side (9 digits, ABA checksum, different from the account number): production rejects a bad one, but development instances accept any 9 digits, so a sandbox run will not catch the typo.\n- Read document_file back with POST \u002Fv1\u002Fpresign?instance_id={instance_id}, which returns a one-hour signed link; upload, extract, and presign all take instance_id as a query parameter. Never expose the raw file URL.\n- Test on a development instance first; use the sentinel amounts ($666.00 forces failed, $777.00 forces refunded) to prove the failure handling.\n\nDeliverables: invoice upload and AI prefill service with a confirmation form, payable registration service, the quote-and-pay path, webhook handlers for both event streams, and an integration test that uploads, registers, and pays a test invoice on the development instance.\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 instance ID.",[38,42,43],{},"Decide where invoice confirmation happens in your UX; the extracted bank fields are what the user must approve before the payable exists.",[38,45,46],{},"Run the full flow on a development instance before touching production.",[15,48,50],{"id":49},"related-docs","Related docs",[52,53,54,63,70,77,84],"ul",{},[38,55,56],{},[57,58,62],"a",{"href":59,"rel":60},"https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fpayable-invoice",[61],"nofollow","Invoice payables",[38,64,65],{},[57,66,69],{"href":67,"rel":68},"https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fpayables",[61],"Payables",[38,71,72],{},[57,73,76],{"href":74,"rel":75},"https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fbank-accounts",[61],"Bank accounts",[38,78,79],{},[57,80,83],{"href":81,"rel":82},"https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fpayout-quotes",[61],"Payout quotes",[38,85,86],{},[57,87,90],{"href":88,"rel":89},"https:\u002F\u002Fblindpay.com\u002Fdocs\u002Flearn\u002Fwebhooks",[61],"Webhooks",{"title":26,"searchDepth":92,"depth":92,"links":93},2,[94,95,96],{"id":17,"depth":92,"text":18},{"id":32,"depth":92,"text":33},{"id":49,"depth":92,"text":50},"integrations","2026-09-02","Register supplier invoices with line items and the vendor's ACH or wire details, prefill them from the PDF with AI, and settle them from stablecoins through the quote-and-execute flow.","md",false,{},true,"\u002Fprompts\u002Fintegrate-invoice-payables",[106,107,108],"payables","quotes","webhooks","---\ntitle: \"Pay US vendor invoices with payables\"\ndescription: \"Register supplier invoices with line items and the vendor's ACH or wire details, prefill them from the PDF with AI, and settle them from stablecoins through the quote-and-execute flow.\"\ndate: \"2026-09-02\"\ncategory: \"integrations\"\nproducts: [\"payables\", \"quotes\", \"webhooks\"]\n---\n\nPaste this prompt into your coding agent to build accounts payable on stablecoins: your users upload a vendor invoice, BlindPay reads it, and pays the vendor's US bank account over ACH or wire.\n\n## Prompt\n\n```text\nYou are integrating BlindPay invoice payables into my application: registering US supplier invoices (line items plus the vendor's ACH or wire bank details) and paying them from stablecoins.\n\nBefore writing code, read these sources and follow them over any prior knowledge:\n- https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fllms.txt (read the payables, invoice payables, bank accounts, payout quotes, payouts, and webhooks pages)\n- The OpenAPI spec: curl https:\u002F\u002Fapi.blindpay.com\u002Fdoc\n\nBuild the flow:\n1. Prerequisites: an approved customer (KYC\u002FKYB) and a funded wallet, managed or external. Reuse my existing onboarding if present.\n2. Upload the invoice: POST \u002Fv1\u002Fupload with bucket `documents`, keep the returned file_url. Then POST \u002Fv1\u002Fupload\u002Fextract?instance_id={instance_id} with the same file to prefill amount, currency, due_date, invoice_number, the `to` party, line_items, and payment_options. Every extracted field is nullable and nothing is guessed, so render the result as an editable form and require the user to confirm the bank fields against the document before submitting.\n3. Register the invoice: POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Fpayables with currency USD, from\u002Fto parties, line_items (name, quantity, unit price in cents), optional note, discount, and taxes, the vendor's bank_account (type `ach` or `wire`, same shape as POST \u002Fcustomers\u002F{customer_id}\u002Fbank-accounts, with beneficiary_name, routing_number, account_number, account_type, account_class, business_industry as a NAICS code whenever account_class is `business`, recipient_relationship, and address), plus document_file set to the file_url from step 2. Pick the ACH payment option when the invoice prints one; it is the cheapest rail. Persist the returned pb_ ID and the derived amount (line item sum plus taxes minus discount).\n4. Quote against the payable: POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Fquotes with payable_id instead of bank_account_id, plus network and token; do not send request_amount or currency_type. Execute with POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Fpayouts\u002Fevm before the quote's expires_at. Show the user the quote's fees and total before executing.\n5. Track the bill through payable.new, payable.update, and payable.complete, and the payment attempt through payout.new, payout.update, and payout.complete, all with Svix signature verification. Correlate the two streams through payable_id and payout_id, and never count a payout.complete and its payable.complete as two payments. The payable stays `processing` while the payout is held for manual review; compliance holds, releases, and failure reasons arrive only on the payout events.\n6. Handle the failure paths explicitly: a failed or refunded attempt returns the payable to `draft` with last_attempt_status set, so quote the same payable again instead of registering it twice; bills under the 10.00 USD minimum are rejected at registration with LIMITS_AMOUNT_OUT_OF_RANGE; a bank_account that fails validation is rejected with payable_bank_account_invalid and the failing field in errors; and a quote that expired must be re-quoted and re-confirmed with the user.\n7. Let the user delete a draft: DELETE \u002Fv1\u002Finstances\u002F{instance_id}\u002Fpayables\u002F{payable_id} works only while no payout exists for it (payable_not_cancelable otherwise).\n\nConstraints:\n- Amounts are integers in cents; line_items[].price is the unit price, so 150000 is $1,500.00. API keys stay server-side.\n- The bank account created for an invoice belongs to the payable: it is not listed with the customer's bank accounts and cannot be quoted on its own, so never reuse it for regular payouts.\n- Invoice payables are USD only and settle on EVM networks. Boleto and PIX bills use a different registration shape; do not mix them into this flow.\n- POST \u002Fupload\u002Fextract is limited to 60 requests per minute per instance and returns a fixed sample on development instances; code the extract-then-confirm step so a null field is a normal case, not an error. The NAICS code is never printed on an invoice, so the form must ask for it.\n- Validate the routing number client-side (9 digits, ABA checksum, different from the account number): production rejects a bad one, but development instances accept any 9 digits, so a sandbox run will not catch the typo.\n- Read document_file back with POST \u002Fv1\u002Fpresign?instance_id={instance_id}, which returns a one-hour signed link; upload, extract, and presign all take instance_id as a query parameter. Never expose the raw file URL.\n- Test on a development instance first; use the sentinel amounts ($666.00 forces failed, $777.00 forces refunded) to prove the failure handling.\n\nDeliverables: invoice upload and AI prefill service with a confirmation form, payable registration service, the quote-and-pay path, webhook handlers for both event streams, and an integration test that uploads, registers, and pays a test invoice on the development instance.\n```\n\n## How to use\n\n1. Paste the prompt with your stack details and instance ID.\n2. Decide where invoice confirmation happens in your UX; the extracted bank fields are what the user must approve before the payable exists.\n3. Run the full flow on a development instance before touching production.\n\n## Related docs\n\n- [Invoice payables](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fpayable-invoice)\n- [Payables](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fpayables)\n- [Bank accounts](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fbank-accounts)\n- [Payout quotes](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fpayout-quotes)\n- [Webhooks](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Flearn\u002Fwebhooks)\n",{"title":5,"description":99},"prompts\u002Fintegrate-invoice-payables","AUaN-AD56K_UDvNtZ9-96pEySaHAUqo9Q1VjPTZQ7p8",[114,118,122,126,130,134,138,142,146,150,154,158,162,166,170,174,178,182,183],{"path":115,"title":116,"description":117},"\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":119,"title":120,"description":121},"\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":123,"title":124,"description":125},"\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":127,"title":128,"description":129},"\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":131,"title":132,"description":133},"\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":135,"title":136,"description":137},"\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":139,"title":140,"description":141},"\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":143,"title":144,"description":145},"\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":147,"title":148,"description":149},"\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":151,"title":152,"description":153},"\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":155,"title":156,"description":157},"\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":159,"title":160,"description":161},"\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":163,"title":164,"description":165},"\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":167,"title":168,"description":169},"\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":171,"title":172,"description":173},"\u002Fprompts\u002Fintegrate-blindpay-wallet","Integrate the BlindPay wallet","Hold customer stablecoin balances in BlindPay-custodied wallets: create the wallet, collect payins into it, pay out from it with no signing step.",{"path":175,"title":176,"description":177},"\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":179,"title":180,"description":181},"\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":104,"title":5,"description":99},{"path":184,"title":185,"description":186},"\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.",1788388150437]