[{"data":1,"prerenderedAt":5310},["ShallowReactive",2],{"changelog-entries":3},[4,141,224,294,383,487,610,670,745,806,893,965,1134,1223,1442,1541,1973,2091,2290,2648,2745,2842,3005,3764,3858,3992,4073,4200],{"id":5,"title":6,"author":7,"body":8,"categories":7,"category":124,"categoryType":125,"date":126,"description":127,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":131,"navigation":130,"path":136,"rawbody":137,"seo":138,"stem":139,"thumbnail":7,"__hash__":140},"content\u002Fchangelog\u002F2025-04-10-us-named-accounts.md","Named Virtual Accounts and API Pagination",null,{"type":9,"value":10,"toc":116},"minimark",[11,15,20,33,37,51,54,71,74,110],[12,13,14],"p",{},"BlindPay delivered the most-requested account features in April, including support for named virtual accounts, a revamped terms of service workflow, and cursor-based pagination across core endpoints.",[16,17,19],"h2",{"id":18},"tldr","TL;DR",[21,22,23,27,30],"ul",{},[24,25,26],"li",{},"US named accounts",[24,28,29],{},"Terms of Service API (breaking changes)",[24,31,32],{},"Pagination (breaking changes)",[16,34,36],{"id":35},"named-virtual-accounts-powered-by-tier-1-bank-in-the-us","Named Virtual Accounts powered by Tier 1 Bank in the US",[12,38,39,40,44,45,50],{},"BlindPay can issue ",[41,42,43],"strong",{},"named"," virtual accounts backed by Tier 1 Bank in the US. This unlocks customer-facing account numbers that display your client's business or individual name instead of BlindPay. We are already onboarding beta testers—",[46,47,49],"a",{"href":48},"mailto:hello@blindpay.com","reach out to us"," if you want early access or pricing details.",[16,52,29],{"id":53},"terms-of-service-api-breaking-changes",[12,55,56,57,61,62,66,67,70],{},"For compliance reasons every customer must accept BlindPay’s terms of service before you can create payouts or payins on their behalf. Update your onboarding flow to capture the ",[58,59,60],"code",{},"tos_id"," returned by the ",[46,63,65],{"href":64},"\u002Fdocs\u002Fessentials\u002Fterms-of-service","Terms of Service endpoint"," and persist it when you create customers. All customers must complete this step by ",[41,68,69],{},"May 30"," to avoid disruptions.",[16,72,32],{"id":73},"pagination-breaking-changes",[12,75,76,77,80,81,84,85,88,89,92,93,96,97,100,101,105,106,109],{},"The ",[58,78,79],{},"\u002Fpayins"," and ",[58,82,83],{},"\u002Fpayouts"," endpoints now support cursor pagination with the ",[58,86,87],{},"limit",", ",[58,90,91],{},"starting_after",", and ",[58,94,95],{},"ending_before"," parameters. The legacy pagination response will be deprecated on ",[41,98,99],{},"June 30",". Review the new parameters in the ",[46,102,104],{"href":103},"\u002Fdocs\u002Fessentials\u002Fpayouts#create-a-payout","API reference"," and add the ",[58,107,108],{},"customer_id"," query filter where needed to segment results by customer.",[12,111,112,113,115],{},"We also added the first filter related to customers, so you can pass the ",[58,114,108],{}," on the query parameter as well.",{"title":117,"searchDepth":118,"depth":118,"links":119},"",2,[120,121,122,123],{"id":18,"depth":118,"text":19},{"id":35,"depth":118,"text":36},{"id":53,"depth":118,"text":29},{"id":73,"depth":118,"text":32},"Product Update","update","2025-04-10","Premium named virtual accounts powered by tier 1 banks displaying your client's business or individual name, mandatory terms of service acceptance workflow for all customers with compliance requirements, and cursor-based pagination across all core API endpoints with enhanced filtering capabilities.","md",false,true,{"excerpt":132},{"type":9,"value":133},[134],[12,135,14],{},"\u002Fchangelog\u002F2025-04-10-us-named-accounts","---\ntitle: Named Virtual Accounts and API Pagination\ndescription: Premium named virtual accounts powered by tier 1 banks displaying your client's business or individual name, mandatory terms of service acceptance workflow for all customers with compliance requirements, and cursor-based pagination across all core API endpoints with enhanced filtering capabilities.\ndate: 2025-04-10\ncategory: Product Update\ncategoryType: update\nisChangelog: true\n---\n\nBlindPay delivered the most-requested account features in April, including support for named virtual accounts, a revamped terms of service workflow, and cursor-based pagination across core endpoints.\n\n\u003C!--more-->\n\n## TL;DR\n\n- US named accounts\n- Terms of Service API (breaking changes)\n- Pagination (breaking changes)\n\n## Named Virtual Accounts powered by Tier 1 Bank in the US\n\nBlindPay can issue **named** virtual accounts backed by Tier 1 Bank in the US. This unlocks customer-facing account numbers that display your client's business or individual name instead of BlindPay. We are already onboarding beta testers—[reach out to us](mailto:hello@blindpay.com) if you want early access or pricing details.\n\n## Terms of Service API (breaking changes)\n\nFor compliance reasons every customer must accept BlindPay’s terms of service before you can create payouts or payins on their behalf. Update your onboarding flow to capture the `tos_id` returned by the [Terms of Service endpoint](\u002Fdocs\u002Fessentials\u002Fterms-of-service) and persist it when you create customers. All customers must complete this step by **May 30** to avoid disruptions.\n\n## Pagination (breaking changes)\n\nThe `\u002Fpayins` and `\u002Fpayouts` endpoints now support cursor pagination with the `limit`, `starting_after`, and `ending_before` parameters. The legacy pagination response will be deprecated on **June 30**. Review the new parameters in the [API reference](\u002Fdocs\u002Fessentials\u002Fpayouts#create-a-payout) and add the `customer_id` query filter where needed to segment results by customer.\n\nWe also added the first filter related to customers, so you can pass the `customer_id` on the query parameter as well.\n",{"title":6,"description":127},"changelog\u002F2025-04-10-us-named-accounts","yvTxmNykkqsUH0Xo1nfNfXyI5usVaKGlYClK4vH8_JI",{"id":142,"title":143,"author":7,"body":144,"categories":7,"category":124,"categoryType":125,"date":212,"description":213,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":214,"navigation":130,"path":219,"rawbody":220,"seo":221,"stem":222,"thumbnail":7,"__hash__":223},"content\u002Fchangelog\u002F2025-05-09-stellar-integration.md","Stellar Integration and SWIFT Collections",{"type":9,"value":145,"toc":206},[146,149,151,162,165,176,179,195,199],[12,147,148],{},"May focused on expanding blockchain coverage and documenting the virtual account experience while we turned on SWIFT collection for every customer with banking access.",[16,150,19],{"id":18},[21,152,153,156,159],{},[24,154,155],{},"Stellar integration",[24,157,158],{},"Virtual accounts documentation",[24,160,161],{},"Support for SWIFT payments",[16,163,155],{"id":164},"stellar-integration",[12,166,167,168,171,172,175],{},"BlindPay now supports Stellar alongside our existing EVM networks. We are joining the Stellar team in Toronto during ",[41,169,170],{},"Consensus 2025"," to help Stellar developers build on top of the BlindPay API. Planning to attend? ",[46,173,174],{"href":48},"Book time with our team"," and we will sync on your roadmap.",[16,177,158],{"id":178},"virtual-accounts-documentation",[12,180,181,182,186,187,190,191,194],{},"Virtual accounts are now fully documented. Visit the ",[46,183,185],{"href":184},"\u002Fdocs\u002Fessentials\u002Fvirtual-accounts","virtual accounts guide"," to review settlement flows, fees, and API usage. Note the upcoming fee adjustments: ACH flat fees move to ",[41,188,189],{},"$0.40"," and wire flat fees move to ",[41,192,193],{},"$15.00"," while percentage-based fees remain unchanged.",[16,196,198],{"id":197},"swift-payments","SWIFT payments",[12,200,201,202,205],{},"Every customer with a virtual account can now collect international SWIFT transfers. We are building a way to send SWIFT payments worldwide using stablecoins. Have a use case already? ",[46,203,204],{"href":48},"Let us know"," so we can include you in the beta.",{"title":117,"searchDepth":118,"depth":118,"links":207},[208,209,210,211],{"id":18,"depth":118,"text":19},{"id":164,"depth":118,"text":155},{"id":178,"depth":118,"text":158},{"id":197,"depth":118,"text":198},"2025-05-09","Expanded blockchain coverage with full Stellar network support alongside existing EVM chains, comprehensive virtual accounts documentation including settlement flows and fee structures, and universal SWIFT transfer collection capabilities for all virtual account customers.",{"excerpt":215},{"type":9,"value":216},[217],[12,218,148],{},"\u002Fchangelog\u002F2025-05-09-stellar-integration","---\ntitle: Stellar Integration and SWIFT Collections\ndescription: Expanded blockchain coverage with full Stellar network support alongside existing EVM chains, comprehensive virtual accounts documentation including settlement flows and fee structures, and universal SWIFT transfer collection capabilities for all virtual account customers.\ndate: 2025-05-09\ncategory: Product Update\ncategoryType: update\nisChangelog: true\n---\n\nMay focused on expanding blockchain coverage and documenting the virtual account experience while we turned on SWIFT collection for every customer with banking access.\n\n\u003C!--more-->\n\n## TL;DR\n\n- Stellar integration\n- Virtual accounts documentation\n- Support for SWIFT payments\n\n## Stellar integration\n\nBlindPay now supports Stellar alongside our existing EVM networks. We are joining the Stellar team in Toronto during **Consensus 2025** to help Stellar developers build on top of the BlindPay API. Planning to attend? [Book time with our team](mailto:hello@blindpay.com) and we will sync on your roadmap.\n\n## Virtual accounts documentation\n\nVirtual accounts are now fully documented. Visit the [virtual accounts guide](\u002Fdocs\u002Fessentials\u002Fvirtual-accounts) to review settlement flows, fees, and API usage. Note the upcoming fee adjustments: ACH flat fees move to **$0.40** and wire flat fees move to **$15.00** while percentage-based fees remain unchanged.\n\n## SWIFT payments\n\nEvery customer with a virtual account can now collect international SWIFT transfers. We are building a way to send SWIFT payments worldwide using stablecoins. Have a use case already? [Let us know](mailto:hello@blindpay.com) so we can include you in the beta.\n",{"title":143,"description":213},"changelog\u002F2025-05-09-stellar-integration","iHeqI5kxGyIuqKwlIsqnqCkz5uRjEFG2we0s-cqLIS0",{"id":225,"title":226,"author":7,"body":227,"categories":7,"category":124,"categoryType":125,"date":282,"description":283,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":284,"navigation":130,"path":289,"rawbody":290,"seo":291,"stem":292,"thumbnail":7,"__hash__":293},"content\u002Fchangelog\u002F2025-06-12-role-based-access-control.md","Team Collaboration and Automated Onramp",{"type":9,"value":228,"toc":276},[229,232,234,245,248,255,258,266,269],[12,230,231],{},"June’s release makes it easier to collaborate inside BlindPay, accelerate fiat-to-stablecoin conversions, and experiment with cross-border payouts via SWIFT.",[16,233,19],{"id":18},[21,235,236,239,242],{},[24,237,238],{},"Role-based access control",[24,240,241],{},"Automated onramp",[24,243,244],{},"Sending international SWIFT (beta)",[16,246,238],{"id":247},"role-based-access-control",[12,249,250,251,254],{},"Collaborate with your team effortlessly! Invite teammates and assign granular permissions so each person has the exact access they need. Navigate to ",[41,252,253],{},"Settings → Team"," to add members, then select capabilities like customer creation, payment execution, or analytics-only visibility.",[16,256,241],{"id":257},"automated-onramp",[12,259,260,261,265],{},"When funds arrive in your virtual account, BlindPay automatically converts them into stablecoin and deposits directly to your chosen blockchain wallet. Choose to receive either USDC or USDT—it's completely automated. Review the configuration steps in the ",[46,262,264],{"href":263},"\u002Fdocs\u002Fessentials\u002F11.payins","payin guide"," to get started.",[16,267,244],{"id":268},"sending-international-swift-beta",[12,270,271,272,275],{},"Send payments globally with ease. With BlindPay's international SWIFT capabilities you'll be able to access the entire world with stablecoins. Want to unlock global payments? ",[46,273,274],{"href":48},"Contact sales"," to enable international corridors on your instance.",{"title":117,"searchDepth":118,"depth":118,"links":277},[278,279,280,281],{"id":18,"depth":118,"text":19},{"id":247,"depth":118,"text":238},{"id":257,"depth":118,"text":241},{"id":268,"depth":118,"text":244},"2025-06-12","Enterprise team collaboration features with granular role-based access control, automated onramp settlement that converts virtual account deposits directly to your preferred stablecoins, and early access to outbound SWIFT payouts powered by stablecoins for global transfers.",{"excerpt":285},{"type":9,"value":286},[287],[12,288,231],{},"\u002Fchangelog\u002F2025-06-12-role-based-access-control","---\ntitle: Team Collaboration and Automated Onramp\ndescription: Enterprise team collaboration features with granular role-based access control, automated onramp settlement that converts virtual account deposits directly to your preferred stablecoins, and early access to outbound SWIFT payouts powered by stablecoins for global transfers.\ndate: 2025-06-12\ncategory: Product Update\ncategoryType: update\nisChangelog: true\n---\n\nJune’s release makes it easier to collaborate inside BlindPay, accelerate fiat-to-stablecoin conversions, and experiment with cross-border payouts via SWIFT.\n\n\u003C!--more-->\n\n## TL;DR\n\n- Role-based access control\n- Automated onramp\n- Sending international SWIFT (beta)\n\n## Role-based access control\n\nCollaborate with your team effortlessly! Invite teammates and assign granular permissions so each person has the exact access they need. Navigate to **Settings → Team** to add members, then select capabilities like customer creation, payment execution, or analytics-only visibility.\n\n## Automated onramp\n\nWhen funds arrive in your virtual account, BlindPay automatically converts them into stablecoin and deposits directly to your chosen blockchain wallet. Choose to receive either USDC or USDT—it's completely automated. Review the configuration steps in the [payin guide](\u002Fdocs\u002Fessentials\u002F11.payins) to get started.\n\n## Sending international SWIFT (beta)\n\nSend payments globally with ease. With BlindPay's international SWIFT capabilities you'll be able to access the entire world with stablecoins. Want to unlock global payments? [Contact sales](mailto:hello@blindpay.com) to enable international corridors on your instance.\n",{"title":226,"description":283},"changelog\u002F2025-06-12-role-based-access-control","VFuLUqBCJWNkdHIhLkfFbOTjvny_ZsbUhJtFvqugRxQ",{"id":295,"title":296,"author":7,"body":297,"categories":7,"category":124,"categoryType":125,"date":371,"description":372,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":373,"navigation":130,"path":378,"rawbody":379,"seo":380,"stem":381,"thumbnail":7,"__hash__":382},"content\u002Fchangelog\u002F2025-07-21-international-swift-available.md","International SWIFT Generally Available",{"type":9,"value":298,"toc":365},[299,302,304,315,319,326,336,339,342,352,355,358],[12,300,301],{},"July marks the general availability of international SWIFT payouts alongside quality-of-life improvements for reporting and payout transparency.",[16,303,19],{"id":18},[21,305,306,309,312],{},[24,307,308],{},"International SWIFT is available",[24,310,311],{},"Export data and filters improved",[24,313,314],{},"Payout receipts",[16,316,318],{"id":317},"international-swift","International SWIFT",[12,320,321,322,325],{},"You can now ",[41,323,324],{},"collect and send"," SWIFT payments using virtual accounts, unlocking instant access to global banking corridors.",[12,327,328,331,332,335],{},[41,329,330],{},"Important compliance reminder:"," All outgoing SWIFT transactions require supporting documentation for validation. This helps ensure secure, compliant transfers that meet international banking standards. Check the ",[46,333,334],{"href":103},"payout API reference"," for details before submitting payouts.",[16,337,311],{"id":338},"export-data-and-filters-improved",[12,340,341],{},"You can now export all your payouts and payins directly from the platform, making it easier to reconcile transactions across your data sources and streamline your financial reporting.",[12,343,344,345,347,348,351],{},"We've also enhanced our filtering capabilities with new status and ",[58,346,108],{}," filters available in both the API and dashboard for more precise transaction management. The ",[46,349,350],{"href":103},"payouts reference"," outlines the latest query parameters.",[16,353,314],{"id":354},"payout-receipts",[12,356,357],{},"BlindPay now automatically generates a receipt document for every completed payout, providing you with professional documentation to share with recipient banks and ensure full transaction transparency.",[12,359,360,361,364],{},"To access your receipts, simply open the external tracking link from any completed payout and click ",[41,362,363],{},"Print receipt"," to download a PDF copy for your records.",{"title":117,"searchDepth":118,"depth":118,"links":366},[367,368,369,370],{"id":18,"depth":118,"text":19},{"id":317,"depth":118,"text":318},{"id":338,"depth":118,"text":311},{"id":354,"depth":118,"text":314},"2025-07-21","International SWIFT payouts now generally available for collecting and sending payments across global banking corridors, enhanced data export functionality with new status and customer filters, and automated payout receipt generation for all completed transactions.",{"excerpt":374},{"type":9,"value":375},[376],[12,377,301],{},"\u002Fchangelog\u002F2025-07-21-international-swift-available","---\ntitle: International SWIFT Generally Available\ndescription: International SWIFT payouts now generally available for collecting and sending payments across global banking corridors, enhanced data export functionality with new status and customer filters, and automated payout receipt generation for all completed transactions.\ndate: 2025-07-21\ncategory: Product Update\ncategoryType: update\nisChangelog: true\n---\n\nJuly marks the general availability of international SWIFT payouts alongside quality-of-life improvements for reporting and payout transparency.\n\n\u003C!--more-->\n\n## TL;DR\n\n- International SWIFT is available\n- Export data and filters improved\n- Payout receipts\n\n## International SWIFT\n\nYou can now **collect and send** SWIFT payments using virtual accounts, unlocking instant access to global banking corridors.\n\n**Important compliance reminder:** All outgoing SWIFT transactions require supporting documentation for validation. This helps ensure secure, compliant transfers that meet international banking standards. Check the [payout API reference](\u002Fdocs\u002Fessentials\u002Fpayouts#create-a-payout) for details before submitting payouts.\n\n## Export data and filters improved\n\nYou can now export all your payouts and payins directly from the platform, making it easier to reconcile transactions across your data sources and streamline your financial reporting.\n\nWe've also enhanced our filtering capabilities with new status and `customer_id` filters available in both the API and dashboard for more precise transaction management. The [payouts reference](\u002Fdocs\u002Fessentials\u002Fpayouts#create-a-payout) outlines the latest query parameters.\n\n## Payout receipts\n\nBlindPay now automatically generates a receipt document for every completed payout, providing you with professional documentation to share with recipient banks and ensure full transaction transparency.\n\nTo access your receipts, simply open the external tracking link from any completed payout and click **Print receipt** to download a PDF copy for your records.\n",{"title":296,"description":372},"changelog\u002F2025-07-21-international-swift-available","zMVeZyb-0MyGiZYJepCtpyJsfKNc3j4wziTk4Rx_gFg",{"id":384,"title":385,"author":7,"body":386,"categories":7,"category":124,"categoryType":125,"date":475,"description":476,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":477,"navigation":130,"path":482,"rawbody":483,"seo":484,"stem":485,"thumbnail":7,"__hash__":486},"content\u002Fchangelog\u002F2025-08-24-rtp-offramp-tron.md","Real-Time Payments and Tron Network Integration",{"type":9,"value":387,"toc":467},[388,391,393,410,414,421,424,432,435,441,444,456,459],[12,389,390],{},"August expands real-time settlement options, adds new blockchain coverage, and tightens compliance for virtual accounts.",[16,392,19],{"id":18},[21,394,395,398,401,404,407],{},[24,396,397],{},"RTP is now live",[24,399,400],{},"Offramp wallets",[24,402,403],{},"Tron network",[24,405,406],{},"On hold transactions",[24,408,409],{},"Virtual accounts countries update (breaking changes)",[16,411,413],{"id":412},"real-time-payments-in-the-us","Real-time payments in the US",[12,415,416,417,420],{},"Now you have access to RTP in the US and can send or collect payments from over 4,000 banks. You don't need to wait for ACH or wire settlement times anymore—just submit an RTP payout and watch it settle in real time. Learn how to configure the rail in the ",[46,418,419],{"href":103},"payout guide",".",[16,422,400],{"id":423},"offramp-wallets",[12,425,426,427,431],{},"Generate a dedicated blockchain wallet that automatically converts supported stablecoins into fiat the moment funds arrive. This is perfect for moving assets directly from exchanges or enterprise custodians. Follow the ",[46,428,430],{"href":429},"\u002Fdocs\u002Fessentials\u002Fofframp-wallets","offramp wallet tutorial"," to begin.",[16,433,403],{"id":434},"tron-network",[12,436,437,438,420],{},"BlindPay now supports the Tron network for offramping USDT. Point your Tron wallets at BlindPay and we will handle the conversion to fiat. Right now this is only supported for offramp wallets. We would love feedback as we expand support to additional networks—",[46,439,440],{"href":48},"drop us a note",[16,442,406],{"id":443},"on-hold-transactions",[12,445,446,447,450,451,455],{},"We improved our transaction monitoring solution to prevent fraudulent activities. Now you will see a new payin status ",[41,448,449],{},"On Hold"," for payments that our KYT software has flagged and our compliance team might request information for before releasing them. The ",[46,452,454],{"href":453},"\u002Fknowledge-base\u002Fguides\u002Fon-hold-transactions","on hold guide"," explains how to respond quickly.",[16,457,409],{"id":458},"virtual-accounts-countries-update-breaking-changes",[12,460,461,462,466],{},"We added a list of high-risk countries where only customers with enhanced due diligence will be able to create a virtual account. Review the latest requirements in the ",[46,463,465],{"href":464},"\u002Fknowledge-base\u002Fguides\u002Fsupported-countries","supported countries guide"," before onboarding new customers.",{"title":117,"searchDepth":118,"depth":118,"links":468},[469,470,471,472,473,474],{"id":18,"depth":118,"text":19},{"id":412,"depth":118,"text":413},{"id":423,"depth":118,"text":400},{"id":434,"depth":118,"text":403},{"id":443,"depth":118,"text":406},{"id":458,"depth":118,"text":409},"2025-08-24","Major platform expansion with real-time payments across 4,000+ US banks via RTP, dedicated offramp wallets for automatic stablecoin conversion, Tron network integration for USDT, enhanced KYT engine with on-hold transaction review, and updated virtual account country requirements.",{"excerpt":478},{"type":9,"value":479},[480],[12,481,390],{},"\u002Fchangelog\u002F2025-08-24-rtp-offramp-tron","---\ntitle: Real-Time Payments and Tron Network Integration\ndescription: Major platform expansion with real-time payments across 4,000+ US banks via RTP, dedicated offramp wallets for automatic stablecoin conversion, Tron network integration for USDT, enhanced KYT engine with on-hold transaction review, and updated virtual account country requirements.\ndate: 2025-08-24\ncategory: Product Update\ncategoryType: update\nisChangelog: true\n---\n\nAugust expands real-time settlement options, adds new blockchain coverage, and tightens compliance for virtual accounts.\n\n\u003C!--more-->\n\n## TL;DR\n\n- RTP is now live\n- Offramp wallets\n- Tron network\n- On hold transactions\n- Virtual accounts countries update (breaking changes)\n\n## Real-time payments in the US\n\nNow you have access to RTP in the US and can send or collect payments from over 4,000 banks. You don't need to wait for ACH or wire settlement times anymore—just submit an RTP payout and watch it settle in real time. Learn how to configure the rail in the [payout guide](\u002Fdocs\u002Fessentials\u002Fpayouts#create-a-payout).\n\n## Offramp wallets\n\nGenerate a dedicated blockchain wallet that automatically converts supported stablecoins into fiat the moment funds arrive. This is perfect for moving assets directly from exchanges or enterprise custodians. Follow the [offramp wallet tutorial](\u002Fdocs\u002Fessentials\u002Fofframp-wallets) to begin.\n\n## Tron network\n\nBlindPay now supports the Tron network for offramping USDT. Point your Tron wallets at BlindPay and we will handle the conversion to fiat. Right now this is only supported for offramp wallets. We would love feedback as we expand support to additional networks—[drop us a note](mailto:hello@blindpay.com).\n\n## On hold transactions\n\nWe improved our transaction monitoring solution to prevent fraudulent activities. Now you will see a new payin status **On Hold** for payments that our KYT software has flagged and our compliance team might request information for before releasing them. The [on hold guide](\u002Fknowledge-base\u002Fguides\u002Fon-hold-transactions) explains how to respond quickly.\n\n## Virtual accounts countries update (breaking changes)\n\nWe added a list of high-risk countries where only customers with enhanced due diligence will be able to create a virtual account. Review the latest requirements in the [supported countries guide](\u002Fknowledge-base\u002Fguides\u002Fsupported-countries) before onboarding new customers.\n",{"title":385,"description":476},"changelog\u002F2025-08-24-rtp-offramp-tron","d2Uyt5Z0MSm0TEFI_ol3A-daA2pURh2-q6V2AsckSjA",{"id":488,"title":489,"author":7,"body":490,"categories":7,"category":594,"categoryType":595,"date":596,"description":597,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":598,"navigation":130,"path":605,"rawbody":606,"seo":607,"stem":608,"thumbnail":7,"__hash__":609},"content\u002Fchangelog\u002F2025-10-06-urgent-compliance-updates.md","Urgent Compliance Updates",{"type":9,"value":491,"toc":589},[492,499,501,509,513,516,528,540,544,547,586],[12,493,494,495,498],{},"These compliance updates take effect on ",[41,496,497],{},"October 15, 2025"," and require action across your customer onboarding and terms of service flows.",[16,500,19],{"id":18},[21,502,503,506],{},[24,504,505],{},"New terms of service available (breaking changes)",[24,507,508],{},"Customer creation updates (breaking changes)",[16,510,512],{"id":511},"new-terms-of-service-version-available","New terms of service version available",[12,514,515],{},"All your customers will be required to accept the new version of our terms of service. This is necessary to allow BlindPay to issue virtual accounts, create wallets and process payments on behalf of them.",[12,517,518,519,522,523,527],{},"Every time you try to create a quote, an error message ",[58,520,521],{},"please_accept_terms_of_service"," will show up. When you see that, you should pop up the terms of service link and make your customer accept. Consult the ",[46,524,526],{"href":525},"\u002Fdocs\u002Fessentials\u002Fterms-of-service#accepting-a-new-version","terms of service guide"," for integration details.",[12,529,530,531,534,535,539],{},"You will also receive updated ",[58,532,533],{},"tos.accept"," webhook events—review the ",[46,536,538],{"href":537},"\u002Fdocs\u002Fessentials\u002Fwebhooks","webhook documentation"," to handle them correctly.",[16,541,543],{"id":542},"customer-creation-updates","Customer creation updates",[12,545,546],{},"The following fields are now updated:",[21,548,549,559,568,574,580],{},[24,550,551,552,80,555,558],{},"The fields ",[58,553,554],{},"phone_number",[58,556,557],{},"selfie_file"," are now mandatory for individuals. This is necessary because our US banking partner will require them in the future, so we're already anticipating this.",[24,560,561,562,565,566,420],{},"The field ",[58,563,564],{},"individual_holding_doc_front_file"," is deprecated for enhanced KYC because of the addition of ",[58,567,557],{},[24,569,561,570,573],{},[58,571,572],{},"website"," is now mandatory for businesses.",[24,575,76,576,579],{},[46,577,578],{"href":464},"prohibited and high-risk countries list"," was updated. All customers from high-risk countries must go through enhanced KYC verification.",[24,581,582,583,420],{},"We're adding new fraud checks when analyzing customer data. If the KYC is rejected, you'll see details in ",[58,584,585],{},"fraud_warnings",[12,587,588],{},"Update your onboarding forms and validation logic ahead of the deadline to avoid interruptions.",{"title":117,"searchDepth":118,"depth":118,"links":590},[591,592,593],{"id":18,"depth":118,"text":19},{"id":511,"depth":118,"text":512},{"id":542,"depth":118,"text":543},"Compliance","improvement","2025-10-06","Critical compliance changes requiring immediate action including mandatory terms of service acceptance for all customers, enhanced KYC requirements with selfie verification, and updated country restrictions for high-risk jurisdictions.",{"excerpt":599},{"type":9,"value":600},[601],[12,602,494,603,498],{},[41,604,497],{},"\u002Fchangelog\u002F2025-10-06-urgent-compliance-updates","---\ntitle: Urgent Compliance Updates\ndescription: Critical compliance changes requiring immediate action including mandatory terms of service acceptance for all customers, enhanced KYC requirements with selfie verification, and updated country restrictions for high-risk jurisdictions.\ndate: 2025-10-06\ncategory: Compliance\ncategoryType: improvement\nisChangelog: true\n---\n\nThese compliance updates take effect on **October 15, 2025** and require action across your customer onboarding and terms of service flows.\n\n\u003C!--more-->\n\n## TL;DR\n\n- New terms of service available (breaking changes)\n- Customer creation updates (breaking changes)\n\n## New terms of service version available\n\nAll your customers will be required to accept the new version of our terms of service. This is necessary to allow BlindPay to issue virtual accounts, create wallets and process payments on behalf of them.\n\nEvery time you try to create a quote, an error message `please_accept_terms_of_service` will show up. When you see that, you should pop up the terms of service link and make your customer accept. Consult the [terms of service guide](\u002Fdocs\u002Fessentials\u002Fterms-of-service#accepting-a-new-version) for integration details.\n\nYou will also receive updated `tos.accept` webhook events—review the [webhook documentation](\u002Fdocs\u002Fessentials\u002Fwebhooks) to handle them correctly.\n\n## Customer creation updates\n\nThe following fields are now updated:\n\n- The fields `phone_number` and `selfie_file` are now mandatory for individuals. This is necessary because our US banking partner will require them in the future, so we're already anticipating this.\n- The field `individual_holding_doc_front_file` is deprecated for enhanced KYC because of the addition of `selfie_file`.\n- The field `website` is now mandatory for businesses.\n- The [prohibited and high-risk countries list](\u002Fknowledge-base\u002Fguides\u002Fsupported-countries) was updated. All customers from high-risk countries must go through enhanced KYC verification.\n- We're adding new fraud checks when analyzing customer data. If the KYC is rejected, you'll see details in `fraud_warnings`.\n\nUpdate your onboarding forms and validation logic ahead of the deadline to avoid interruptions.\n",{"title":489,"description":597},"changelog\u002F2025-10-06-urgent-compliance-updates","TJ_ev1nABoH9onYItTgSzIcH2nqGIvMbeh-289uEN2s",{"id":611,"title":612,"author":7,"body":613,"categories":7,"category":124,"categoryType":125,"date":662,"description":663,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":664,"navigation":130,"path":665,"rawbody":666,"seo":667,"stem":668,"thumbnail":7,"__hash__":669},"content\u002Fchangelog\u002F2025-10-20-new-sdks-solana-and-eth-main-net-support.md","New SDKS, Solana and ETH Main Net Support",{"type":9,"value":614,"toc":656},[615,618,620,631,634,637,640,643,646,649,653],[12,616,617],{},"We're excited to announce the release of new SDKS, Solana and ETH Main Net Support.",[16,619,19],{"id":18},[21,621,622,625,628],{},[24,623,624],{},"Ethereum Mainnet and Solana Devnet Support",[24,626,627],{},"Self-Service Customer Limit Increases",[24,629,630],{},"New SDKs: Node, Python, and Go",[16,632,624],{"id":633},"ethereum-mainnet-and-solana-devnet-support",[12,635,636],{},"You can now send and collect USDC or USDT on Ethereum Mainnet.\nEthereum integration works the same way as other EVM chains you're\nalready familiar with.",[12,638,639],{},"Solana Devnet is now available on Development Instances using USDB.\nCheck out our Solana documentation for implementation details.",[16,641,627],{"id":642},"self-service-customer-limit-increases",[12,644,645],{},"Request limit increases directly through the dashboard or API—no more\nemails to our compliance team.",[12,647,648],{},"Submit your request with supporting documents via the dashboard or\nAPI, and our compliance team will review it within 24 hours. You'll receive\nwebhook notifications for every status change and can track the full\nhistory of your requests. Check our API reference.",[16,650,652],{"id":651},"node-python-and-go-sdks","Node, Python and Go SDKs",[12,654,655],{},"We're committed to delivering the best developer experience in the\nindustry. Our new Node SDK , Python SDK , and Go SDK make\nintegration faster and easier than ever.\nWe're also updating our website with more detailed guides and examples\nto help you get the most out of our APIs.",{"title":117,"searchDepth":118,"depth":118,"links":657},[658,659,660,661],{"id":18,"depth":118,"text":19},{"id":633,"depth":118,"text":624},{"id":642,"depth":118,"text":627},{"id":651,"depth":118,"text":652},"2025-10-20","Accelerate your integration with our new Node.js, Python, and Go SDKs while expanding your blockchain capabilities with Ethereum Mainnet and Solana Devnet support. Plus, manage your customer limits more efficiently with our new self-service request system that delivers compliance reviews within 24 hours, eliminating the need for email communications.",{},"\u002Fchangelog\u002F2025-10-20-new-sdks-solana-and-eth-main-net-support","---\ntitle: New SDKS, Solana and ETH Main Net Support\ndescription: Accelerate your integration with our new Node.js, Python, and Go SDKs while expanding your blockchain capabilities with Ethereum Mainnet and Solana Devnet support. Plus, manage your customer limits more efficiently with our new self-service request system that delivers compliance reviews within 24 hours, eliminating the need for email communications.\ndate: 2025-10-20\ncategory: Product Update\ncategoryType: update\nisChangelog: true\n---\n\nWe're excited to announce the release of new SDKS, Solana and ETH Main Net Support.\n\n## TL;DR\n\n- Ethereum Mainnet and Solana Devnet Support\n- Self-Service Customer Limit Increases\n- New SDKs: Node, Python, and Go\n\n## Ethereum Mainnet and Solana Devnet Support\n\nYou can now send and collect USDC or USDT on Ethereum Mainnet.\nEthereum integration works the same way as other EVM chains you're\nalready familiar with.\n\nSolana Devnet is now available on Development Instances using USDB.\nCheck out our Solana documentation for implementation details.\n\n## Self-Service Customer Limit Increases\n\nRequest limit increases directly through the dashboard or API—no more\nemails to our compliance team.\n\nSubmit your request with supporting documents via the dashboard or\nAPI, and our compliance team will review it within 24 hours. You'll receive\nwebhook notifications for every status change and can track the full\nhistory of your requests. Check our API reference.\n\n## Node, Python and Go SDKs\n\nWe're committed to delivering the best developer experience in the\nindustry. Our new Node SDK , Python SDK , and Go SDK make\nintegration faster and easier than ever.\nWe're also updating our website with more detailed guides and examples\nto help you get the most out of our APIs.\n",{"title":612,"description":663},"changelog\u002F2025-10-20-new-sdks-solana-and-eth-main-net-support","3tBvAm4QOUOIIDVbzD_bfF1GVNHDReIG_lKmTWz1plM",{"id":671,"title":672,"author":7,"body":673,"categories":7,"category":124,"categoryType":125,"date":733,"description":734,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":735,"navigation":130,"path":740,"rawbody":741,"seo":742,"stem":743,"thumbnail":7,"__hash__":744},"content\u002Fchangelog\u002F2025-11-21-new-website-solana-offramp-and-swift-sdk.md","New Website, Solana Offramp, and Swift SDK",{"type":9,"value":674,"toc":727},[675,678,680,691,694,703,707,715,719],[12,676,677],{},"We're excited to announce major platform improvements including a refreshed website, expanded blockchain support, and new developer tools.",[16,679,19],{"id":18},[21,681,682,685,688],{},[24,683,684],{},"New Website",[24,686,687],{},"Solana offramp wallets is now live",[24,689,690],{},"New Swift SDK",[16,692,684],{"id":693},"new-website",[12,695,696,697],{},"Our belief is simple: great developer experience and stablecoin abstraction will be the competitive advantage in the stablecoin space. We've completely refreshed our website to reflect this vision. ",[46,698,702],{"href":699,"rel":700},"https:\u002F\u002Fblindpay.com\u002F",[701],"nofollow","Check it out here.",[16,704,706],{"id":705},"solana-offramp-wallet","Solana Offramp Wallet",[12,708,709,710],{},"You can now generate a Solana wallet that automatically offramps all USDC transactions. Full Solana support across the BlindPay ecosystem is coming soon. ",[46,711,714],{"href":712,"rel":713},"https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fessentials\u002Fofframp-wallets",[701],"View documentation.",[16,716,718],{"id":717},"swift-sdk","Swift SDK",[12,720,721,722],{},"Apple developers can now integrate BlindPay with just a few lines of code. ",[46,723,726],{"href":724,"rel":725},"https:\u002F\u002Fgithub.com\u002Fblindpaylabs\u002Fblindpay-swift",[701],"See GitHub docs.",{"title":117,"searchDepth":118,"depth":118,"links":728},[729,730,731,732],{"id":18,"depth":118,"text":19},{"id":693,"depth":118,"text":684},{"id":705,"depth":118,"text":706},{"id":717,"depth":118,"text":718},"2025-11-21","Major platform improvements including a completely refreshed website, Solana offramp wallet support, and a new Swift SDK for Apple developers.",{"excerpt":736},{"type":9,"value":737},[738],[12,739,677],{},"\u002Fchangelog\u002F2025-11-21-new-website-solana-offramp-and-swift-sdk","---\ntitle: New Website, Solana Offramp, and Swift SDK\ndescription: Major platform improvements including a completely refreshed website, Solana offramp wallet support, and a new Swift SDK for Apple developers.\ndate: 2025-11-21\ncategory: Product Update\ncategoryType: update\nisChangelog: true\n---\n\nWe're excited to announce major platform improvements including a refreshed website, expanded blockchain support, and new developer tools.\n\n\u003C!--more-->\n\n## TL;DR\n\n- New Website\n- Solana offramp wallets is now live\n- New Swift SDK\n\n## New Website\n\nOur belief is simple: great developer experience and stablecoin abstraction will be the competitive advantage in the stablecoin space. We've completely refreshed our website to reflect this vision. [Check it out here.](https:\u002F\u002Fblindpay.com\u002F)\n\n## Solana Offramp Wallet\n\nYou can now generate a Solana wallet that automatically offramps all USDC transactions. Full Solana support across the BlindPay ecosystem is coming soon. [View documentation.](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fessentials\u002Fofframp-wallets)\n\n## Swift SDK\n\nApple developers can now integrate BlindPay with just a few lines of code. [See GitHub docs.](https:\u002F\u002Fgithub.com\u002Fblindpaylabs\u002Fblindpay-swift)\n",{"title":672,"description":734},"changelog\u002F2025-11-21-new-website-solana-offramp-and-swift-sdk","1QI3P8kj1JcFYIcEnJS4hdFcX0o8eqKu7rwEFZb9I0Y",{"id":746,"title":747,"author":7,"body":748,"categories":7,"category":594,"categoryType":595,"date":790,"description":791,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":792,"navigation":130,"path":801,"rawbody":802,"seo":803,"stem":804,"thumbnail":7,"__hash__":805},"content\u002Fchangelog\u002F2025-12-09-compliance-updates-for-poa.md","BlindPay Compliance Updates - December",{"type":9,"value":749,"toc":785},[750,755,758,760,768,771,779,782],[12,751,752],{},[41,753,754],{},"All these updates will take effect on January 8th, 2026.",[12,756,757],{},"Important compliance changes are coming to BlindPay's onboarding process to ensure continued regulatory compliance.",[16,759,19],{"id":18},[21,761,762,765],{},[24,763,764],{},"PoA documents for UBOs are now mandatory",[24,766,767],{},"New updates to Business PoA documents",[16,769,764],{"id":770},"poa-documents-for-ubos-are-now-mandatory",[12,772,773,774,420],{},"Starting January 8th, 2026, it will be mandatory for all Ultimate Beneficial Owners (UBOs) to submit a valid proof of address document as part of the onboarding process. For comprehensive guidance on accepted documents and submission procedures, please refer to the ",[46,775,778],{"href":776,"rel":777},"https:\u002F\u002Fapi.blindpay.com\u002Freference#tag\u002Fcustomers\u002FPOST\u002Fv1\u002Finstances\u002F%7Binstance_id%7D\u002Fcustomers.body.owners",[701],"documentation here",[16,780,767],{"id":781},"new-updates-to-business-poa-documents",[12,783,784],{},"If you are onboarding a contractor or freelancer company in Brazil (with a single UBO), and the company's registered address is that of the accountant, we will accept a document co-signed by both the accountant and the UBO. This document should clearly explain their relationship and the reason for using the accountant's address as the company's official registration.",{"title":117,"searchDepth":118,"depth":118,"links":786},[787,788,789],{"id":18,"depth":118,"text":19},{"id":770,"depth":118,"text":764},{"id":781,"depth":118,"text":767},"2025-12-09","Important compliance updates including mandatory PoA documents for UBOs and new updates to Business PoA documents, effective January 8th, 2026.",{"excerpt":793},{"type":9,"value":794},[795,799],[12,796,797],{},[41,798,754],{},[12,800,757],{},"\u002Fchangelog\u002F2025-12-09-compliance-updates-for-poa","---\ntitle: BlindPay Compliance Updates - December\ndescription: Important compliance updates including mandatory PoA documents for UBOs and new updates to Business PoA documents, effective January 8th, 2026.\ndate: 2025-12-09\ncategory: Compliance\ncategoryType: improvement\nisChangelog: true\n---\n\n**All these updates will take effect on January 8th, 2026.**\n\nImportant compliance changes are coming to BlindPay's onboarding process to ensure continued regulatory compliance.\n\n\u003C!--more-->\n\n## TL;DR\n\n- PoA documents for UBOs are now mandatory\n- New updates to Business PoA documents\n\n## PoA documents for UBOs are now mandatory\n\nStarting January 8th, 2026, it will be mandatory for all Ultimate Beneficial Owners (UBOs) to submit a valid proof of address document as part of the onboarding process. For comprehensive guidance on accepted documents and submission procedures, please refer to the [documentation here](https:\u002F\u002Fapi.blindpay.com\u002Freference#tag\u002Fcustomers\u002FPOST\u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers.body.owners).\n\n## New updates to Business PoA documents\n\nIf you are onboarding a contractor or freelancer company in Brazil (with a single UBO), and the company's registered address is that of the accountant, we will accept a document co-signed by both the accountant and the UBO. This document should clearly explain their relationship and the reason for using the accountant's address as the company's official registration.\n",{"title":747,"description":791},"changelog\u002F2025-12-09-compliance-updates-for-poa","yuLNFQIPb8NLA0cTJHSAnh7ct16O6n0GpTWTbBKh48g",{"id":807,"title":808,"author":7,"body":809,"categories":7,"category":124,"categoryType":125,"date":881,"description":882,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":883,"navigation":130,"path":888,"rawbody":889,"seo":890,"stem":891,"thumbnail":7,"__hash__":892},"content\u002Fchangelog\u002F2025-12-23-onramp-argentina-colombia-multiple-virtual-accounts-solana.md","Onramp in Argentina & Colombia, Multiple Virtual Accounts, and Full Solana Support",{"type":9,"value":810,"toc":874},[811,814,816,830,833,841,844,852,855,863,866],[12,812,813],{},"We're excited to announce major product updates including expanded geographic coverage, enhanced virtual account capabilities, full Solana deployment, and improved privacy features.",[16,815,19],{"id":18},[21,817,818,821,824,827],{},[24,819,820],{},"Onramp in Argentina and Colombia",[24,822,823],{},"Multiple Virtual Accounts",[24,825,826],{},"Solana is Fully Deployed",[24,828,829],{},"New Upload Endpoint",[16,831,820],{"id":832},"onramp-in-argentina-and-colombia",[12,834,835,836],{},"Now you can collect payments in Argentina and Colombia, both in real time. BlindPay is adding two new rails: Transfers 3.0 for Argentina and PSE Colombia, enabling your customers to fund their accounts instantly using local payment methods. ",[46,837,840],{"href":838,"rel":839},"https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fessentials\u002Fpayin-quotes#create-a-payin-quote",[701],"Integrate it now.",[16,842,823],{"id":843},"multiple-virtual-accounts",[12,845,846,847],{},"You can now issue multiple virtual accounts for every customer, allowing you to separate funds by purpose and better organize your payment flows. ",[46,848,851],{"href":849,"rel":850},"https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fessentials\u002Fvirtual-accounts#generate-a-virtual-account",[701],"See the documentation.",[16,853,826],{"id":854},"solana-is-fully-deployed",[12,856,857,858],{},"All BlindPay features are now live on Solana, including payins, payouts, and virtual accounts. This means you can leverage Solana's fast transaction speeds and low fees across our entire product suite, giving you another powerful blockchain option alongside our existing networks. ",[46,859,862],{"href":860,"rel":861},"https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fessentials\u002Fpayouts#creating-a-payout-on-solana",[701],"Learn more.",[16,864,829],{"id":865},"new-upload-endpoint",[12,867,868,869],{},"The new endpoint allows you to handle user privacy and data protection in the best way possible: simply upload the required documents, receive a secure URL, and use it to complete the verification process. This streamlines your compliance workflow while maintaining the highest privacy standards. ",[46,870,873],{"href":871,"rel":872},"https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fessentials\u002Fupload",[701],"Start integration.",{"title":117,"searchDepth":118,"depth":118,"links":875},[876,877,878,879,880],{"id":18,"depth":118,"text":19},{"id":832,"depth":118,"text":820},{"id":843,"depth":118,"text":823},{"id":854,"depth":118,"text":826},{"id":865,"depth":118,"text":829},"2025-12-23","Major product updates including onramp support for Argentina and Colombia, multiple virtual accounts per customer, full Solana deployment, and a new upload endpoint for enhanced privacy and compliance.",{"excerpt":884},{"type":9,"value":885},[886],[12,887,813],{},"\u002Fchangelog\u002F2025-12-23-onramp-argentina-colombia-multiple-virtual-accounts-solana","---\ntitle: Onramp in Argentina & Colombia, Multiple Virtual Accounts, and Full Solana Support\ndescription: Major product updates including onramp support for Argentina and Colombia, multiple virtual accounts per customer, full Solana deployment, and a new upload endpoint for enhanced privacy and compliance.\ndate: 2025-12-23\ncategory: Product Update\ncategoryType: update\nisChangelog: true\n---\n\nWe're excited to announce major product updates including expanded geographic coverage, enhanced virtual account capabilities, full Solana deployment, and improved privacy features.\n\n\u003C!--more-->\n\n## TL;DR\n\n- Onramp in Argentina and Colombia\n- Multiple Virtual Accounts\n- Solana is Fully Deployed\n- New Upload Endpoint\n\n## Onramp in Argentina and Colombia\n\nNow you can collect payments in Argentina and Colombia, both in real time. BlindPay is adding two new rails: Transfers 3.0 for Argentina and PSE Colombia, enabling your customers to fund their accounts instantly using local payment methods. [Integrate it now.](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fessentials\u002Fpayin-quotes#create-a-payin-quote)\n\n## Multiple Virtual Accounts\n\nYou can now issue multiple virtual accounts for every customer, allowing you to separate funds by purpose and better organize your payment flows. [See the documentation.](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fessentials\u002Fvirtual-accounts#generate-a-virtual-account)\n\n## Solana is Fully Deployed\n\nAll BlindPay features are now live on Solana, including payins, payouts, and virtual accounts. This means you can leverage Solana's fast transaction speeds and low fees across our entire product suite, giving you another powerful blockchain option alongside our existing networks. [Learn more.](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fessentials\u002Fpayouts#creating-a-payout-on-solana)\n\n## New Upload Endpoint\n\nThe new endpoint allows you to handle user privacy and data protection in the best way possible: simply upload the required documents, receive a secure URL, and use it to complete the verification process. This streamlines your compliance workflow while maintaining the highest privacy standards. [Start integration.](https:\u002F\u002Fblindpay.com\u002Fdocs\u002Fessentials\u002Fupload)\n",{"title":808,"description":882},"changelog\u002F2025-12-23-onramp-argentina-colombia-multiple-virtual-accounts-solana","zR7D7dcWGwk91kPNjnN9qc1cKMcWrblbdlwcJfbHJUg",{"id":894,"title":895,"author":7,"body":896,"categories":7,"category":124,"categoryType":125,"date":953,"description":954,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":955,"navigation":130,"path":960,"rawbody":961,"seo":962,"stem":963,"thumbnail":7,"__hash__":964},"content\u002Fchangelog\u002F2026-01-21-mcp-launch-uetr-infrastructure-upgrade.md","BlindPay MCP Launch, UETR Tracking, and Infrastructure Upgrade",{"type":9,"value":897,"toc":947},[898,901,903,914,917,925,929,941,944],[12,899,900],{},"We're excited to announce major product updates including Model Context Protocol integration for AI-powered workflows, enhanced payout tracking capabilities, and significant infrastructure improvements for better performance and security.",[16,902,19],{"id":18},[21,904,905,908,911],{},[24,906,907],{},"BlindPay MCP Launch",[24,909,910],{},"Infrastructure Upgrade and Security",[24,912,913],{},"UETR, ACH Trace ID and Wire IMAD",[16,915,907],{"id":916},"blindpay-mcp-launch",[12,918,919,920],{},"Now you can ask Cursor or Claude Code to collect data from customers, bank accounts, pay-ins, and payouts. You can also build reports or initiate payments as needed. ",[46,921,924],{"href":922,"rel":923},"https:\u002F\u002Fblindpay.com\u002Fblog\u002Fmcp",[701],"Integrate with our MCP now.",[16,926,928],{"id":927},"uetr-ach-trace-id-and-wire-imad","UETR, ACH Trace ID, and Wire IMAD",[12,930,931,932,935,936],{},"New fields have been added to the payout API. Every day, we will now update ",[58,933,934],{},"jpm_track_data"," to show all information for SWIFT UETR, ACH Trace ID, and Wire IMAD. ",[46,937,940],{"href":938,"rel":939},"https:\u002F\u002Fapi.blindpay.com\u002Freference#tag\u002Fpayouts",[701],"Check our documentation.",[16,942,910],{"id":943},"infrastructure-upgrade-and-security",[12,945,946],{},"We migrated all our infrastructure to AWS and we're targeting SOC 2 by Q1 2026. This means the response time from all our services is faster and more secure.",{"title":117,"searchDepth":118,"depth":118,"links":948},[949,950,951,952],{"id":18,"depth":118,"text":19},{"id":916,"depth":118,"text":907},{"id":927,"depth":118,"text":928},{"id":943,"depth":118,"text":910},"2026-01-21","Major product updates including Model Context Protocol integration, enhanced payout tracking with UETR, ACH Trace ID, and Wire IMAD, plus infrastructure migration to AWS with improved security and performance.",{"excerpt":956},{"type":9,"value":957},[958],[12,959,900],{},"\u002Fchangelog\u002F2026-01-21-mcp-launch-uetr-infrastructure-upgrade","---\ntitle: BlindPay MCP Launch, UETR Tracking, and Infrastructure Upgrade\ndescription: Major product updates including Model Context Protocol integration, enhanced payout tracking with UETR, ACH Trace ID, and Wire IMAD, plus infrastructure migration to AWS with improved security and performance.\ndate: 2026-01-21\ncategory: Product Update\ncategoryType: update\nisChangelog: true\n---\n\nWe're excited to announce major product updates including Model Context Protocol integration for AI-powered workflows, enhanced payout tracking capabilities, and significant infrastructure improvements for better performance and security.\n\n\u003C!--more-->\n\n## TL;DR\n\n- BlindPay MCP Launch\n- Infrastructure Upgrade and Security\n- UETR, ACH Trace ID and Wire IMAD\n\n## BlindPay MCP Launch\n\nNow you can ask Cursor or Claude Code to collect data from customers, bank accounts, pay-ins, and payouts. You can also build reports or initiate payments as needed. [Integrate with our MCP now.](https:\u002F\u002Fblindpay.com\u002Fblog\u002Fmcp)\n\n## UETR, ACH Trace ID, and Wire IMAD\n\nNew fields have been added to the payout API. Every day, we will now update `jpm_track_data` to show all information for SWIFT UETR, ACH Trace ID, and Wire IMAD. [Check our documentation.](https:\u002F\u002Fapi.blindpay.com\u002Freference#tag\u002Fpayouts)\n\n## Infrastructure Upgrade and Security\n\nWe migrated all our infrastructure to AWS and we're targeting SOC 2 by Q1 2026. This means the response time from all our services is faster and more secure.\n",{"title":895,"description":954},"changelog\u002F2026-01-21-mcp-launch-uetr-infrastructure-upgrade","DgFxomfA-rKHEtEJ3SSHsNZ9WK3OgUmrx8yCBMBl2i8",{"id":966,"title":967,"author":7,"body":968,"categories":7,"category":594,"categoryType":595,"date":1120,"description":1121,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":1122,"navigation":130,"path":1129,"rawbody":1130,"seo":1131,"stem":1132,"thumbnail":7,"__hash__":1133},"content\u002Fchangelog\u002F2026-01-26-us-bank-account-breaking-changes.md","US Bank Account Breaking Changes",{"type":9,"value":969,"toc":1111},[970,975,977,991,995,998,1001,1004,1042,1045,1048,1059,1063,1066,1083,1087,1095,1099,1105],[12,971,972],{},[41,973,974],{},"All US bank accounts created until January 26th, 2026 have been deprecated and will be deleted soon. Please DO NOT use the offramp wallets related to deprecated US bank accounts. All transactions will get stuck and will need to be refunded.",[16,976,19],{"id":18},[21,978,979,982,985,988],{},[24,980,981],{},"New mandatory fields for ACH bank accounts",[24,983,984],{},"New mandatory fields for Wire\u002FRTP bank accounts",[24,986,987],{},"New mandatory fields for SWIFT bank accounts",[24,989,990],{},"All deprecated US bank accounts must be recreated",[16,992,994],{"id":993},"why-are-we-making-these-changes","Why are we making these changes?",[12,996,997],{},"We are getting compliant with the new US banking partners we're adding to the BlindPay ecosystem. These changes will ensure that all transactions are processed correctly, with BlindPay or the virtual account holder as the debitor and the recipient as the creditor.",[16,999,981],{"id":1000},"new-mandatory-fields-for-ach-bank-accounts",[12,1002,1003],{},"When creating an ACH bank account, the following fields are now mandatory:",[21,1005,1006,1011,1016,1022,1027,1032,1037],{},[24,1007,1008],{},[58,1009,1010],{},"recipient_relationship",[24,1012,1013],{},[58,1014,1015],{},"address_line_1",[24,1017,1018,1021],{},[58,1019,1020],{},"address_line_2"," (optional)",[24,1023,1024],{},[58,1025,1026],{},"city",[24,1028,1029],{},[58,1030,1031],{},"state_province_region",[24,1033,1034],{},[58,1035,1036],{},"country",[24,1038,1039],{},[58,1040,1041],{},"postal_code",[16,1043,984],{"id":1044},"new-mandatory-fields-for-wirertp-bank-accounts",[12,1046,1047],{},"When creating a Wire or RTP bank account, the following fields are now mandatory:",[21,1049,1050,1055],{},[24,1051,1052],{},[58,1053,1054],{},"account_class",[24,1056,1057],{},[58,1058,1010],{},[16,1060,1062],{"id":1061},"new-fields-for-swift-bank-accounts","New fields for SWIFT bank accounts",[12,1064,1065],{},"When creating a SWIFT bank account, the following fields have been added:",[21,1067,1068,1073,1077],{},[24,1069,1070,1072],{},[58,1071,1054],{}," (mandatory)",[24,1074,1075,1072],{},[58,1076,1010],{},[24,1078,1079,1082],{},[58,1080,1081],{},"swift_payment_code"," (required only for: PK, PH, KE, JP, IN, ID, CN, CH, BH)",[16,1084,1086],{"id":1085},"how-to-get-the-new-field-requirements","How to get the new field requirements",[12,1088,1089,1090,420],{},"All new fields and their validation rules can be requested on the ",[46,1091,1094],{"href":1092,"rel":1093},"https:\u002F\u002Fapi.blindpay.com\u002Freference#tag\u002Favailable\u002FGET\u002Fv1\u002Favailable\u002Fbank-details",[701],"available bank details endpoint",[16,1096,1098],{"id":1097},"what-this-means-for-you","What this means for you",[12,1100,1101,1104],{},[41,1102,1103],{},"Action required:"," You will need to recreate all US bank accounts (ACH, Wire, RTP, and SWIFT) with the new mandatory fields.",[12,1106,1107,1110],{},[41,1108,1109],{},"Benefits:"," All transactions will be sent correctly, with BlindPay or the virtual account holder as the debitor and the recipient as the creditor. This ensures compliance with US banking regulations and improves transaction reliability.",{"title":117,"searchDepth":118,"depth":118,"links":1112},[1113,1114,1115,1116,1117,1118,1119],{"id":18,"depth":118,"text":19},{"id":993,"depth":118,"text":994},{"id":1000,"depth":118,"text":981},{"id":1044,"depth":118,"text":984},{"id":1061,"depth":118,"text":1062},{"id":1085,"depth":118,"text":1086},{"id":1097,"depth":118,"text":1098},"2026-01-26","New compliance updates including new mandatory fields for ACH, Wire\u002FRTP, and SWIFT bank accounts. All US bank accounts created before January 26th, 2026 must be recreated with the new required fields.",{"excerpt":1123},{"type":9,"value":1124},[1125],[12,1126,1127],{},[41,1128,974],{},"\u002Fchangelog\u002F2026-01-26-us-bank-account-breaking-changes","---\ntitle: US Bank Account Breaking Changes\ndescription: New compliance updates including new mandatory fields for ACH, Wire\u002FRTP, and SWIFT bank accounts. All US bank accounts created before January 26th, 2026 must be recreated with the new required fields.\ndate: 2026-01-26\ncategory: Compliance\ncategoryType: improvement\nisChangelog: true\n---\n\n**All US bank accounts created until January 26th, 2026 have been deprecated and will be deleted soon. Please DO NOT use the offramp wallets related to deprecated US bank accounts. All transactions will get stuck and will need to be refunded.**\n\n\u003C!--more-->\n\n## TL;DR\n\n- New mandatory fields for ACH bank accounts\n- New mandatory fields for Wire\u002FRTP bank accounts\n- New mandatory fields for SWIFT bank accounts\n- All deprecated US bank accounts must be recreated\n\n## Why are we making these changes?\n\nWe are getting compliant with the new US banking partners we're adding to the BlindPay ecosystem. These changes will ensure that all transactions are processed correctly, with BlindPay or the virtual account holder as the debitor and the recipient as the creditor.\n\n## New mandatory fields for ACH bank accounts\n\nWhen creating an ACH bank account, the following fields are now mandatory:\n\n- `recipient_relationship`\n- `address_line_1`\n- `address_line_2` (optional)\n- `city`\n- `state_province_region`\n- `country`\n- `postal_code`\n\n## New mandatory fields for Wire\u002FRTP bank accounts\n\nWhen creating a Wire or RTP bank account, the following fields are now mandatory:\n\n- `account_class`\n- `recipient_relationship`\n\n## New fields for SWIFT bank accounts\n\nWhen creating a SWIFT bank account, the following fields have been added:\n\n- `account_class` (mandatory)\n- `recipient_relationship` (mandatory)\n- `swift_payment_code` (required only for: PK, PH, KE, JP, IN, ID, CN, CH, BH)\n\n## How to get the new field requirements\n\nAll new fields and their validation rules can be requested on the [available bank details endpoint](https:\u002F\u002Fapi.blindpay.com\u002Freference#tag\u002Favailable\u002FGET\u002Fv1\u002Favailable\u002Fbank-details).\n\n## What this means for you\n\n**Action required:** You will need to recreate all US bank accounts (ACH, Wire, RTP, and SWIFT) with the new mandatory fields.\n\n**Benefits:** All transactions will be sent correctly, with BlindPay or the virtual account holder as the debitor and the recipient as the creditor. This ensures compliance with US banking regulations and improves transaction reliability.\n",{"title":967,"description":1121},"changelog\u002F2026-01-26-us-bank-account-breaking-changes","-KPmfxZfZaBkrWwnkGkb2qKrlijl1DVHl-a_8Z6Mn20",{"id":1135,"title":1136,"author":7,"body":1137,"categories":7,"category":594,"categoryType":595,"date":1215,"description":1216,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":1217,"navigation":130,"path":1218,"rawbody":1219,"seo":1220,"stem":1221,"thumbnail":7,"__hash__":1222},"content\u002Fchangelog\u002F2026-02-04-swift-requirements.md","SWIFT Payout Document Verification",{"type":9,"value":1138,"toc":1210},[1139,1142,1155,1157,1168,1170,1173,1177,1180,1207],[12,1140,1141],{},"All international SWIFT payouts now require compliance document submission\nbefore funds are processed. Payouts remain on hold until documents are\nsubmitted and approved by our compliance team.",[12,1143,1144,1145,80,1149,420],{},"For technical details, check ",[46,1146,1148],{"href":1147},"\u002Fknowledge-base\u002Fguides\u002Fswift-statuses","our documentation",[46,1150,1154],{"href":1151,"rel":1152,"target":1153},"https:\u002F\u002Fapi.blindpay.com\u002Freference#tag\u002Fpayouts\u002FPOST\u002Fv1\u002Finstances\u002F%7Binstance_id%7D\u002Fpayouts\u002F%7Bid%7D\u002Fdocuments",[701],"\\_blank","Api reference",[16,1156,19],{"id":18},[21,1158,1159,1162,1165],{},[24,1160,1161],{},"SWIFT payouts now require document upload before processing",[24,1163,1164],{},"Payouts remain on hold while documents are reviewed",[24,1166,1167],{},"Documents can be resubmitted if rejected",[16,1169,994],{"id":993},[12,1171,1172],{},"International transfers via SWIFT require additional compliance\ndocumentation to meet regulatory requirements. This verification process\nensures all cross-border payments are properly documented and compliant with\ninternational banking standards.",[16,1174,1176],{"id":1175},"new-payout-flow-for-swift","New payout flow for SWIFT",[12,1178,1179],{},"When you create a SWIFT payout, the flow is now:",[1181,1182,1183,1189,1195,1201],"ol",{},[24,1184,1185,1188],{},[41,1186,1187],{},"Payout created"," → On hold while documentation is not provided or under review",[24,1190,1191,1194],{},[41,1192,1193],{},"Documents submitted"," → Compliance review begins",[24,1196,1197,1200],{},[41,1198,1199],{},"Compliance approved"," → Payout proceeds normally",[24,1202,1203,1206],{},[41,1204,1205],{},"Compliance rejected"," → Submit updated documents and review restarts",[12,1208,1209],{},"Compliance review timing varies based on region and case complexity. Payouts remain on hold pending approval, with an 8-hour SLA for document review.",{"title":117,"searchDepth":118,"depth":118,"links":1211},[1212,1213,1214],{"id":18,"depth":118,"text":19},{"id":993,"depth":118,"text":994},{"id":1175,"depth":118,"text":1176},"2026-02-04","New compliance requirement for international SWIFT payouts. All SWIFT payouts now require document upload and compliance review before processing.",{},"\u002Fchangelog\u002F2026-02-04-swift-requirements","---\ntitle: SWIFT Payout Document Verification\ndescription: New compliance requirement for international SWIFT payouts. All SWIFT payouts now require document upload and compliance review before processing.\ndate: 2026-02-04\ncategory: Compliance\ncategoryType: improvement\nisChangelog: true\n---\n\nAll international SWIFT payouts now require compliance document submission\nbefore funds are processed. Payouts remain on hold until documents are\nsubmitted and approved by our compliance team.\n\nFor technical details, check [our documentation](\u002Fknowledge-base\u002Fguides\u002Fswift-statuses) and [Api reference](https:\u002F\u002Fapi.blindpay.com\u002Freference#tag\u002Fpayouts\u002FPOST\u002Fv1\u002Finstances\u002F%7Binstance_id%7D\u002Fpayouts\u002F%7Bid%7D\u002Fdocuments){target=\"\\_blank\"}.\n\n## TL;DR\n\n- SWIFT payouts now require document upload before processing\n- Payouts remain on hold while documents are reviewed\n- Documents can be resubmitted if rejected\n\n## Why are we making these changes?\n\nInternational transfers via SWIFT require additional compliance\ndocumentation to meet regulatory requirements. This verification process\nensures all cross-border payments are properly documented and compliant with\ninternational banking standards.\n\n## New payout flow for SWIFT\n\nWhen you create a SWIFT payout, the flow is now:\n\n1. **Payout created** → On hold while documentation is not provided or under review\n2. **Documents submitted** → Compliance review begins\n3. **Compliance approved** → Payout proceeds normally\n4. **Compliance rejected** → Submit updated documents and review restarts\n\nCompliance review timing varies based on region and case complexity. Payouts remain on hold pending approval, with an 8-hour SLA for document review.\n",{"title":1136,"description":1216},"changelog\u002F2026-02-04-swift-requirements","5FB1Sm-6zWRS2lIXNluACBN3cVhssJWaO_jU84acwaw",{"id":1224,"title":1225,"author":7,"body":1226,"categories":7,"category":124,"categoryType":125,"date":1426,"description":1427,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":1428,"navigation":130,"path":1437,"rawbody":1438,"seo":1439,"stem":1440,"thumbnail":7,"__hash__":1441},"content\u002Fchangelog\u002F2026-02-18-ach-rtp-us-launch-and-bank-account-rules.md","ACH and RTP Payouts in the US — New Banking Partner",{"type":9,"value":1227,"toc":1411},[1228,1235,1238,1240,1276,1280,1285,1309,1313,1328,1332,1339,1343,1357,1361,1372,1376,1389,1393,1404,1406],[12,1229,1230,1231,1234],{},"We're launching ",[41,1232,1233],{},"ACH and RTP payouts in the US"," with a new banking partner — no Virtual Accounts needed.",[12,1236,1237],{},"All ACH and RTP bank accounts have been deprecated. New fields and rules apply to bank account creation for both ACH and RTP.",[16,1239,19],{"id":18},[21,1241,1242,1245,1248,1255,1262,1269],{},[24,1243,1244],{},"ACH and RTP payouts now available in the US with a new banking partner (no Virtual Accounts)",[24,1246,1247],{},"All existing ACH and RTP bank accounts are deprecated — new accounts must be created with the new rules",[24,1249,1250,1251,1254],{},"Business customers require ",[58,1252,1253],{},"business_industry"," (NAICS code)",[24,1256,1257,1258,1261],{},"Individual customers require local ",[58,1259,1260],{},"tax_id"," (e.g. CPF for Brazil, SSN for US)",[24,1263,1264,1265,1268],{},"ACH and RTP payouts are capped at ",[41,1266,1267],{},"$50K"," for now",[24,1270,1271,1272,1275],{},"All USD payouts will go to ",[41,1273,1274],{},"compliance_reviewing"," for manual review during the first few days",[16,1277,1279],{"id":1278},"rules-you-need-to-know","Rules you need to know",[1281,1282,1284],"h3",{"id":1283},"customer-level-rules","Customer-level rules",[21,1286,1287,1296],{},[24,1288,1289,1292,1293,1295],{},[41,1290,1291],{},"Business customers:"," You must add ",[58,1294,1253],{}," (NAICS code) when the customer is a business.",[24,1297,1298,1301,1302,1304,1305,1308],{},[41,1299,1300],{},"Individual customers:"," You must set ",[58,1303,1260],{}," to the ",[41,1306,1307],{},"local"," tax ID for the beneficiary's country (e.g. CPF for Brazil, SSN for the US). The system validates and formats it per country where required.",[1281,1310,1312],{"id":1311},"payout-limits-and-status","Payout limits and status",[21,1314,1315,1322],{},[24,1316,1317,1318,1321],{},"All ACH and RTP payouts are ",[41,1319,1320],{},"capped at $50K"," for now.",[24,1323,1324,1325,1327],{},"All USD payouts will be pushed to ",[41,1326,1274],{}," status so our team can manually review them for the first few days.",[16,1329,1331],{"id":1330},"bank-account-creation-new-fields-and-rules","Bank account creation — New fields and rules",[12,1333,1334,1335,1338],{},"These rules apply to ",[41,1336,1337],{},"both ACH and RTP"," bank account creation.",[1281,1340,1342],{"id":1341},"business-accounts","Business accounts",[21,1344,1345],{},[24,1346,1347,1349,1350,1353,1354,420],{},[58,1348,1253],{}," (NAICS code) is ",[41,1351,1352],{},"required"," when the customer or account class is ",[58,1355,1356],{},"\"business\"",[1281,1358,1360],{"id":1359},"individual-customers","Individual customers",[21,1362,1363],{},[24,1364,1365,1367,1368,1371],{},[58,1366,1260],{}," must be the ",[41,1369,1370],{},"local tax ID"," for the beneficiary’s country (e.g. CPF for Brazil, SSN for the US). The system validates and formats it per country where required.",[1281,1373,1375],{"id":1374},"phone-number","Phone number",[21,1377,1378],{},[24,1379,1380,1382,1383,1385,1386,420],{},[58,1381,554],{}," is ",[41,1384,1352],{}," when the beneficiary’s country is one of: ",[41,1387,1388],{},"BR, CN, CO, HK, MY, MX, PH, UG, UY",[1281,1390,1392],{"id":1391},"tax-id","Tax ID",[21,1394,1395],{},[24,1396,1397,1382,1399,1385,1401,420],{},[58,1398,1260],{},[41,1400,1352],{},[41,1402,1403],{},"AR, BY, BR, CL, CN, CO, CR, EC, GT, HN, JP, KZ, KR, MX, PK, PE, PH, RU, TH, UY",[16,1405,1098],{"id":1097},[12,1407,1408,1410],{},[41,1409,1103],{}," Recreate any ACH or RTP bank accounts with the new required fields and rules. Do not use deprecated ACH or RTP bank accounts.",{"title":117,"searchDepth":118,"depth":118,"links":1412},[1413,1414,1419,1425],{"id":18,"depth":118,"text":19},{"id":1278,"depth":118,"text":1279,"children":1415},[1416,1418],{"id":1283,"depth":1417,"text":1284},3,{"id":1311,"depth":1417,"text":1312},{"id":1330,"depth":118,"text":1331,"children":1420},[1421,1422,1423,1424],{"id":1341,"depth":1417,"text":1342},{"id":1359,"depth":1417,"text":1360},{"id":1374,"depth":1417,"text":1375},{"id":1391,"depth":1417,"text":1392},{"id":1097,"depth":118,"text":1098},"2026-02-18","Launch of ACH and RTP payouts in the US with a new banking partner (no Virtual Accounts needed).",{"excerpt":1429},{"type":9,"value":1430},[1431,1435],[12,1432,1230,1433,1234],{},[41,1434,1233],{},[12,1436,1237],{},"\u002Fchangelog\u002F2026-02-18-ach-rtp-us-launch-and-bank-account-rules","---\ntitle: ACH and RTP Payouts in the US — New Banking Partner\ndescription: Launch of ACH and RTP payouts in the US with a new banking partner (no Virtual Accounts needed).\ndate: 2026-02-18\ncategory: Product Update\ncategoryType: update\nisChangelog: true\n---\n\nWe're launching **ACH and RTP payouts in the US** with a new banking partner — no Virtual Accounts needed.\n\nAll ACH and RTP bank accounts have been deprecated. New fields and rules apply to bank account creation for both ACH and RTP.\n\n\u003C!--more-->\n\n## TL;DR\n\n- ACH and RTP payouts now available in the US with a new banking partner (no Virtual Accounts)\n- All existing ACH and RTP bank accounts are deprecated — new accounts must be created with the new rules\n- Business customers require `business_industry` (NAICS code)\n- Individual customers require local `tax_id` (e.g. CPF for Brazil, SSN for US)\n- ACH and RTP payouts are capped at **$50K** for now\n- All USD payouts will go to **compliance_reviewing** for manual review during the first few days\n\n## Rules you need to know\n\n### Customer-level rules\n\n- **Business customers:** You must add `business_industry` (NAICS code) when the customer is a business.\n- **Individual customers:** You must set `tax_id` to the **local** tax ID for the beneficiary's country (e.g. CPF for Brazil, SSN for the US). The system validates and formats it per country where required.\n\n### Payout limits and status\n\n- All ACH and RTP payouts are **capped at $50K** for now.\n- All USD payouts will be pushed to **compliance_reviewing** status so our team can manually review them for the first few days.\n\n## Bank account creation — New fields and rules\n\nThese rules apply to **both ACH and RTP** bank account creation.\n\n### Business accounts\n\n- `business_industry` (NAICS code) is **required** when the customer or account class is `\"business\"`.\n\n### Individual customers\n\n- `tax_id` must be the **local tax ID** for the beneficiary’s country (e.g. CPF for Brazil, SSN for the US). The system validates and formats it per country where required.\n\n### Phone number\n\n- `phone_number` is **required** when the beneficiary’s country is one of: **BR, CN, CO, HK, MY, MX, PH, UG, UY**.\n\n### Tax ID\n\n- `tax_id` is **required** when the beneficiary’s country is one of: **AR, BY, BR, CL, CN, CO, CR, EC, GT, HN, JP, KZ, KR, MX, PK, PE, PH, RU, TH, UY**.\n\n## What this means for you\n\n**Action required:** Recreate any ACH or RTP bank accounts with the new required fields and rules. Do not use deprecated ACH or RTP bank accounts.\n",{"title":1225,"description":1427},"changelog\u002F2026-02-18-ach-rtp-us-launch-and-bank-account-rules","EL2v3e9lsI_X8MlTJuYwEoYNdfSwDNgXtzT5v9ZxKsM",{"id":1443,"title":1444,"author":7,"body":1445,"categories":7,"category":124,"categoryType":125,"date":1529,"description":1530,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":1531,"navigation":130,"path":1536,"rawbody":1537,"seo":1538,"stem":1539,"thumbnail":7,"__hash__":1540},"content\u002Fchangelog\u002F2026-02-26-virtual-accounts-billing-blindpay-skills.md","New Banking Partner for Virtual Accounts, Billing Revamp, and BlindPay Skills",{"type":9,"value":1446,"toc":1523},[1447,1450,1452,1463,1467,1478,1484,1488,1491,1506,1509,1516],[12,1448,1449],{},"February closes with a new banking partner for virtual accounts, a rebuilt billing system, and AI skills that let your coding assistant handle BlindPay integrations.",[16,1451,19],{"id":18},[21,1453,1454,1457,1460],{},[24,1455,1456],{},"New banking partner for virtual accounts (beta)",[24,1458,1459],{},"Billing and partner fees revamped",[24,1461,1462],{},"BlindPay Skills",[16,1464,1466],{"id":1465},"new-banking-partner-for-virtual-accounts","New Banking Partner for Virtual Accounts",[12,1468,1469,1470,1473,1474,1477],{},"Issue virtual accounts for your customers with full support for ",[41,1471,1472],{},"ACH, Wire, and SWIFT",". All transactions, inbound and outbound, are named, and a ",[41,1475,1476],{},"UETR"," is provided for external tracking. Sender data is also collected on payins, giving you full visibility into who's sending funds to each virtual account.",[12,1479,1480,1481],{},"This integration requires a few additional fields. ",[46,1482,1483],{"href":184},"Explore documentation",[16,1485,1487],{"id":1486},"billing-and-partner-fees-revamped","Billing and Partner Fees Revamped",[12,1489,1490],{},"The billing system has been rebuilt from the ground up. You can now see exactly what BlindPay charges per payment method and blockchain in one place.",[12,1492,1493,1494,1497,1498,1501,1502],{},"Partner fees have moved from ",[41,1495,1496],{},"per-transaction"," to a ",[41,1499,1500],{},"monthly settlement model",". All fees are consolidated and collectible at the end of each month from the new billing page. ",[46,1503,1505],{"href":1504},"\u002Fdocs\u002Fessentials\u002Fpartner-fees","Review partner fees",[16,1507,1462],{"id":1508},"blindpay-skills",[12,1510,1511,1512,1515],{},"Give your AI coding assistant — ",[41,1513,1514],{},"Cursor, Claude Code, Codex",", and others — instant knowledge of BlindPay's API and payment infrastructure. Install once, and your AI handles the integration.",[12,1517,1518],{},[46,1519,1522],{"href":1520,"rel":1521},"https:\u002F\u002Fgithub.com\u002Fblindpaylabs\u002Fblindpay-skills",[701],"Learn more about BlindPay Skills",{"title":117,"searchDepth":118,"depth":118,"links":1524},[1525,1526,1527,1528],{"id":18,"depth":118,"text":19},{"id":1465,"depth":118,"text":1466},{"id":1486,"depth":118,"text":1487},{"id":1508,"depth":118,"text":1462},"2026-02-26","Virtual accounts with full ACH, Wire, and SWIFT support via a new banking partner, a rebuilt billing and partner fees system with monthly settlements, and AI-powered BlindPay Skills for instant API integration.",{"excerpt":1532},{"type":9,"value":1533},[1534],[12,1535,1449],{},"\u002Fchangelog\u002F2026-02-26-virtual-accounts-billing-blindpay-skills","---\ntitle: New Banking Partner for Virtual Accounts, Billing Revamp, and BlindPay Skills\ndescription: Virtual accounts with full ACH, Wire, and SWIFT support via a new banking partner, a rebuilt billing and partner fees system with monthly settlements, and AI-powered BlindPay Skills for instant API integration.\ndate: 2026-02-26\ncategory: Product Update\ncategoryType: update\nisChangelog: true\n---\n\nFebruary closes with a new banking partner for virtual accounts, a rebuilt billing system, and AI skills that let your coding assistant handle BlindPay integrations.\n\n\u003C!--more-->\n\n## TL;DR\n\n- New banking partner for virtual accounts (beta)\n- Billing and partner fees revamped\n- BlindPay Skills\n\n## New Banking Partner for Virtual Accounts\n\nIssue virtual accounts for your customers with full support for **ACH, Wire, and SWIFT**. All transactions, inbound and outbound, are named, and a **UETR** is provided for external tracking. Sender data is also collected on payins, giving you full visibility into who's sending funds to each virtual account.\n\nThis integration requires a few additional fields. [Explore documentation](\u002Fdocs\u002Fessentials\u002Fvirtual-accounts)\n\n## Billing and Partner Fees Revamped\n\nThe billing system has been rebuilt from the ground up. You can now see exactly what BlindPay charges per payment method and blockchain in one place.\n\nPartner fees have moved from **per-transaction** to a **monthly settlement model**. All fees are consolidated and collectible at the end of each month from the new billing page. [Review partner fees](\u002Fdocs\u002Fessentials\u002Fpartner-fees)\n\n## BlindPay Skills\n\nGive your AI coding assistant — **Cursor, Claude Code, Codex**, and others — instant knowledge of BlindPay's API and payment infrastructure. Install once, and your AI handles the integration.\n\n[Learn more about BlindPay Skills](https:\u002F\u002Fgithub.com\u002Fblindpaylabs\u002Fblindpay-skills)\n",{"title":1444,"description":1530},"changelog\u002F2026-02-26-virtual-accounts-billing-blindpay-skills","Jw5PJsaxDmbT3-0IqQMUDcKno3zNEnRGLRoXmwDne2I",{"id":1542,"title":1543,"author":7,"body":1544,"categories":7,"category":124,"categoryType":125,"date":1961,"description":1962,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":1963,"navigation":130,"path":1968,"rawbody":1969,"seo":1970,"stem":1971,"thumbnail":7,"__hash__":1972},"content\u002Fchangelog\u002F2026-03-06-new-billing-system.md","New Billing System",{"type":9,"value":1545,"toc":1951},[1546,1549,1551,1582,1585,1589,1592,1597,1605,1610,1642,1644,1648,1651,1656,1694,1699,1702,1704,1708,1711,1716,1727,1732,1752,1754,1758,1761,1766,1777,1782,1803,1805,1809,1816,1821,1865,1867,1871,1874,1879,1917,1922,1925,1927,1931],[12,1547,1548],{},"We've rebuilt BlindPay's billing infrastructure from the ground up. The new system replaces per-transaction partner fee settlements with a consolidated monthly billing model, introduces a transparent fee breakdown on every invoice, and gives you a new billing screen to manage invoices, payments, and partner fee claims, all in one place.",[16,1550,19],{"id":18},[21,1552,1553,1556,1559,1562,1565,1568,1571,1579],{},[24,1554,1555],{},"Monthly invoicing with automated generation on the 1st of each month",[24,1557,1558],{},"Transparent fee breakdown on every invoice",[24,1560,1561],{},"Partner fees moved from per-transaction to monthly settlement",[24,1563,1564],{},"Pay invoices via Stripe (card or US bank account) or stablecoins (USDT on Tron, USDC on Solana)",[24,1566,1567],{},"New billing screen with real-time usage tracking",[24,1569,1570],{},"Automated email notifications and overdue management",[24,1572,1573,1574],{},"Plan upgrade is one click and one call away — see ",[46,1575,1578],{"href":1576,"rel":1577},"https:\u002F\u002Fwww.blindpay.com\u002Fpricing",[701],"blindpay.com\u002Fpricing",[24,1580,1581],{},"Addons support for custom recurring charges (e.g., SWIFT access)",[1583,1584],"hr",{},[16,1586,1588],{"id":1587},"monthly-invoicing","Monthly Invoicing",[12,1590,1591],{},"Invoices are now generated automatically on the 1st of each month, covering the previous calendar month. Each invoice consolidates all your charges and partner fee earnings into a single document, giving you a clear picture of what you owe or what you've earned.",[12,1593,1594],{},[41,1595,1596],{},"How it works:",[21,1598,1599,1602],{},[24,1600,1601],{},"Invoices are generated on the 1st of every month",[24,1603,1604],{},"Each invoice covers a full calendar month (e.g., Feb 1 – Feb 28)",[12,1606,1607],{},[41,1608,1609],{},"Invoices can have the following statuses:",[21,1611,1612,1618,1624,1630,1636],{},[24,1613,1614,1617],{},[41,1615,1616],{},"Owing"," — Invoice is unpaid, waiting for payment",[24,1619,1620,1623],{},[41,1621,1622],{},"Paid"," — Payment has been received",[24,1625,1626,1629],{},[41,1627,1628],{},"Claimable"," — You have partner fees to claim",[24,1631,1632,1635],{},[41,1633,1634],{},"Collected"," — Partner fees have been sent to your wallet",[24,1637,1638,1641],{},[41,1639,1640],{},"Overdue"," — Invoice is past the due date",[1583,1643],{},[16,1645,1647],{"id":1646},"transparent-fee-breakdown","Transparent Fee Breakdown",[12,1649,1650],{},"Every invoice now shows an itemized breakdown of your charges, so you always know exactly what you're being billed for.",[12,1652,1653],{},[41,1654,1655],{},"Invoices include the following line items:",[21,1657,1658,1664,1670,1676,1682,1688],{},[24,1659,1660,1663],{},[41,1661,1662],{},"Subscription plan amount"," — Your monthly plan fee (Basic, Business, or Enterprise)",[24,1665,1666,1669],{},[41,1667,1668],{},"Virtual account fees"," — Charged per active KYC-approved virtual account",[24,1671,1672,1675],{},[41,1673,1674],{},"Payin billing fees"," — Transaction fees collected on inbound payments",[24,1677,1678,1681],{},[41,1679,1680],{},"Payout billing fees"," — Transaction fees on outbound payments",[24,1683,1684,1687],{},[41,1685,1686],{},"Partner fee earnings"," — Your share of transaction fees, shown as a credit that offsets your charges",[24,1689,1690,1693],{},[41,1691,1692],{},"Addons"," — Recurring charges like SWIFT access, etc.",[12,1695,1696],{},[41,1697,1698],{},"Invoice calculation:",[12,1700,1701],{},"Your net amount is calculated as total charges minus partner fee earnings. If a minimum monthly amount applies to your plan, the minimum is used when your net is below it. If your partner fee earnings exceed your charges, the excess is claimable — you get paid instead.",[1583,1703],{},[16,1705,1707],{"id":1706},"partner-fees-monthly-settlement","Partner Fees — Monthly Settlement",[12,1709,1710],{},"Partner fees have transitioned from per-transaction settlements to a monthly settlement model. Instead of receiving a blockchain transfer after every transaction, your partner fee earnings are now accumulated throughout the month and settled on the invoice.",[12,1712,1713],{},[41,1714,1715],{},"What changed:",[21,1717,1718,1721,1724],{},[24,1719,1720],{},"Partner fees are calculated per transaction and tracked in each quote (payin and payout)",[24,1722,1723],{},"At the end of the month, all partner fees are totaled and applied as a credit on your invoice",[24,1725,1726],{},"If your partner fee earnings exceed your charges, the remaining balance is claimable directly to your wallet",[12,1728,1729],{},[41,1730,1731],{},"How to claim partner fees:",[1181,1733,1734,1737,1746,1749],{},[24,1735,1736],{},"Open the invoice in the billing screen",[24,1738,1739,1740,1742,1743],{},"If the invoice status is ",[41,1741,1628],{},", click ",[41,1744,1745],{},"Collect",[24,1747,1748],{},"Enter your wallet address (EVM-compatible, e.g., Polygon)",[24,1750,1751],{},"BlindPay sends USDT to your wallet, typically arrives within a few minutes",[1583,1753],{},[16,1755,1757],{"id":1756},"multiple-payment-methods","Multiple Payment Methods",[12,1759,1760],{},"You can pay invoices via Stripe (credit card or US bank account) or directly with stablecoins on the blockchain.",[12,1762,1763],{},[41,1764,1765],{},"Stripe payments:",[21,1767,1768,1771,1774],{},[24,1769,1770],{},"Add a credit card or US bank account via the Stripe Customer Portal",[24,1772,1773],{},"Invoices can be paid directly through the Stripe-hosted invoice page",[24,1775,1776],{},"Manage your payment methods at any time from the billing screen",[12,1778,1779],{},[41,1780,1781],{},"Blockchain payments (USDT on Tron, USDC on Solana):",[1181,1783,1784,1794,1797,1800],{},[24,1785,1786,1787,1790,1791],{},"Open an invoice and click ",[41,1788,1789],{},"Pay",", then select ",[41,1792,1793],{},"Blockchain",[24,1795,1796],{},"A dedicated wallet address is displayed along with the exact amount to send",[24,1798,1799],{},"Send the exact amount of stablecoins to the wallet address",[24,1801,1802],{},"Payment is detected automatically and the invoice status updates within minutes",[1583,1804],{},[16,1806,1808],{"id":1807},"billing-screen","Billing Screen",[12,1810,1811,1812,1815],{},"A completely new billing screen is available under ",[41,1813,1814],{},"Settings > Billing"," in the BlindPay app.",[12,1817,1818],{},[41,1819,1820],{},"What you'll find:",[21,1822,1823,1829,1835,1841,1847,1853,1859],{},[24,1824,1825,1828],{},[41,1826,1827],{},"Subscription card"," — Your current plan, status, and subscription start date",[24,1830,1831,1834],{},[41,1832,1833],{},"Current usage"," — Real-time view of your charges for the current billing period, including virtual account count, payin\u002Fpayout fees, partner fee earnings, and addons",[24,1836,1837,1840],{},[41,1838,1839],{},"Invoice history"," — All past invoices with status, amounts, and links to the Stripe-hosted invoice",[24,1842,1843,1846],{},[41,1844,1845],{},"Invoice detail view"," — Click any invoice to see the full breakdown: fees, partner fee earnings, addons, discounts, and credit notes",[24,1848,1849,1852],{},[41,1850,1851],{},"Fees table"," — Expandable table showing your payin and payout fee rates per payment method (ACH, Wire, Pix, SWIFT, etc.) and per blockchain network (Tron, Ethereum, Polygon, etc.)",[24,1854,1855,1858],{},[41,1856,1857],{},"Payment method"," — View your saved payment method and open the Stripe Customer Portal to update it",[24,1860,1861,1864],{},[41,1862,1863],{},"Billing details"," — Manage your billing contact information (name, email, tax ID, and address). All billing-related communications are sent to the billing email set here; if none is configured, the instance owner's email is used as fallback.",[1583,1866],{},[16,1868,1870],{"id":1869},"automated-notifications-and-overdue-management","Automated Notifications and Overdue Management",[12,1872,1873],{},"You'll receive email notifications throughout the invoice lifecycle to help you stay on top of payments.",[12,1875,1876],{},[41,1877,1878],{},"Notification schedule:",[21,1880,1881,1887,1893,1899,1905,1911],{},[24,1882,1883,1886],{},[41,1884,1885],{},"Invoice created"," — \"Your Invoice is Ready\" email with amount, due date, and a link to view and pay the invoice",[24,1888,1889,1892],{},[41,1890,1891],{},"7 days before due"," — Upcoming invoice reminder",[24,1894,1895,1898],{},[41,1896,1897],{},"2 days before due"," — Payment reminder",[24,1900,1901,1904],{},[41,1902,1903],{},"Due date"," — Due today notice",[24,1906,1907,1910],{},[41,1908,1909],{},"1 business day overdue"," — Past due alert",[24,1912,1913,1916],{},[41,1914,1915],{},"4+ business days overdue"," — Overdue action required",[12,1918,1919],{},[41,1920,1921],{},"Overdue blocking:",[12,1923,1924],{},"If an invoice remains unpaid for more than 4 business days past the due date, the instance is automatically blocked. Blocked instances cannot process new transactions. An instance is unblocked only when no invoice is overdue for more than 4 business days. After paying the overdue invoice, the instance is unblocked automatically.",[1583,1926],{},[16,1928,1930],{"id":1929},"migration-notes","Migration Notes",[21,1932,1933,1939,1945],{},[24,1934,1935,1938],{},[41,1936,1937],{},"Partner fee settlement model changed",": Partner fees are no longer sent per transaction. All partner fee earnings are accumulated and settled monthly via the invoice.",[24,1940,1941,1944],{},[41,1942,1943],{},"Fee structure updated",": Fees are now structured per payment method and per blockchain network.",[24,1946,1947,1950],{},[41,1948,1949],{},"Stripe and blockchain payments",": Each instance is linked to a Stripe customer. Invoices are created in Stripe with itemized line items and can be paid through Stripe or via blockchain with stablecoins.",{"title":117,"searchDepth":118,"depth":118,"links":1952},[1953,1954,1955,1956,1957,1958,1959,1960],{"id":18,"depth":118,"text":19},{"id":1587,"depth":118,"text":1588},{"id":1646,"depth":118,"text":1647},{"id":1706,"depth":118,"text":1707},{"id":1756,"depth":118,"text":1757},{"id":1807,"depth":118,"text":1808},{"id":1869,"depth":118,"text":1870},{"id":1929,"depth":118,"text":1930},"2026-03-06","We've rebuilt BlindPay's billing infrastructure from the ground up with monthly invoicing, transparent fee breakdowns, partner fee monthly settlements, multiple payment methods, and a new billing screen.",{"excerpt":1964},{"type":9,"value":1965},[1966],[12,1967,1548],{},"\u002Fchangelog\u002F2026-03-06-new-billing-system","---\ntitle: New Billing System\ndescription: We've rebuilt BlindPay's billing infrastructure from the ground up with monthly invoicing, transparent fee breakdowns, partner fee monthly settlements, multiple payment methods, and a new billing screen.\ndate: 2026-03-06\ncategory: Product Update\ncategoryType: update\nisChangelog: true\n---\n\nWe've rebuilt BlindPay's billing infrastructure from the ground up. The new system replaces per-transaction partner fee settlements with a consolidated monthly billing model, introduces a transparent fee breakdown on every invoice, and gives you a new billing screen to manage invoices, payments, and partner fee claims, all in one place.\n\n\u003C!--more-->\n\n## TL;DR\n\n- Monthly invoicing with automated generation on the 1st of each month\n- Transparent fee breakdown on every invoice\n- Partner fees moved from per-transaction to monthly settlement\n- Pay invoices via Stripe (card or US bank account) or stablecoins (USDT on Tron, USDC on Solana)\n- New billing screen with real-time usage tracking\n- Automated email notifications and overdue management\n- Plan upgrade is one click and one call away — see [blindpay.com\u002Fpricing](https:\u002F\u002Fwww.blindpay.com\u002Fpricing)\n- Addons support for custom recurring charges (e.g., SWIFT access)\n\n---\n\n## Monthly Invoicing\n\nInvoices are now generated automatically on the 1st of each month, covering the previous calendar month. Each invoice consolidates all your charges and partner fee earnings into a single document, giving you a clear picture of what you owe or what you've earned.\n\n**How it works:**\n\n- Invoices are generated on the 1st of every month\n- Each invoice covers a full calendar month (e.g., Feb 1 – Feb 28)\n\n**Invoices can have the following statuses:**\n\n- **Owing** — Invoice is unpaid, waiting for payment\n- **Paid** — Payment has been received\n- **Claimable** — You have partner fees to claim\n- **Collected** — Partner fees have been sent to your wallet\n- **Overdue** — Invoice is past the due date\n\n---\n\n## Transparent Fee Breakdown\n\nEvery invoice now shows an itemized breakdown of your charges, so you always know exactly what you're being billed for.\n\n**Invoices include the following line items:**\n\n- **Subscription plan amount** — Your monthly plan fee (Basic, Business, or Enterprise)\n- **Virtual account fees** — Charged per active KYC-approved virtual account\n- **Payin billing fees** — Transaction fees collected on inbound payments\n- **Payout billing fees** — Transaction fees on outbound payments\n- **Partner fee earnings** — Your share of transaction fees, shown as a credit that offsets your charges\n- **Addons** — Recurring charges like SWIFT access, etc.\n\n**Invoice calculation:**\n\nYour net amount is calculated as total charges minus partner fee earnings. If a minimum monthly amount applies to your plan, the minimum is used when your net is below it. If your partner fee earnings exceed your charges, the excess is claimable — you get paid instead.\n\n---\n\n## Partner Fees — Monthly Settlement\n\nPartner fees have transitioned from per-transaction settlements to a monthly settlement model. Instead of receiving a blockchain transfer after every transaction, your partner fee earnings are now accumulated throughout the month and settled on the invoice.\n\n**What changed:**\n\n- Partner fees are calculated per transaction and tracked in each quote (payin and payout)\n- At the end of the month, all partner fees are totaled and applied as a credit on your invoice\n- If your partner fee earnings exceed your charges, the remaining balance is claimable directly to your wallet\n\n**How to claim partner fees:**\n\n1. Open the invoice in the billing screen\n2. If the invoice status is **Claimable**, click **Collect**\n3. Enter your wallet address (EVM-compatible, e.g., Polygon)\n4. BlindPay sends USDT to your wallet, typically arrives within a few minutes\n\n---\n\n## Multiple Payment Methods\n\nYou can pay invoices via Stripe (credit card or US bank account) or directly with stablecoins on the blockchain.\n\n**Stripe payments:**\n\n- Add a credit card or US bank account via the Stripe Customer Portal\n- Invoices can be paid directly through the Stripe-hosted invoice page\n- Manage your payment methods at any time from the billing screen\n\n**Blockchain payments (USDT on Tron, USDC on Solana):**\n\n1. Open an invoice and click **Pay**, then select **Blockchain**\n2. A dedicated wallet address is displayed along with the exact amount to send\n3. Send the exact amount of stablecoins to the wallet address\n4. Payment is detected automatically and the invoice status updates within minutes\n\n---\n\n## Billing Screen\n\nA completely new billing screen is available under **Settings > Billing** in the BlindPay app.\n\n**What you'll find:**\n\n- **Subscription card** — Your current plan, status, and subscription start date\n- **Current usage** — Real-time view of your charges for the current billing period, including virtual account count, payin\u002Fpayout fees, partner fee earnings, and addons\n- **Invoice history** — All past invoices with status, amounts, and links to the Stripe-hosted invoice\n- **Invoice detail view** — Click any invoice to see the full breakdown: fees, partner fee earnings, addons, discounts, and credit notes\n- **Fees table** — Expandable table showing your payin and payout fee rates per payment method (ACH, Wire, Pix, SWIFT, etc.) and per blockchain network (Tron, Ethereum, Polygon, etc.)\n- **Payment method** — View your saved payment method and open the Stripe Customer Portal to update it\n- **Billing details** — Manage your billing contact information (name, email, tax ID, and address). All billing-related communications are sent to the billing email set here; if none is configured, the instance owner's email is used as fallback.\n\n---\n\n## Automated Notifications and Overdue Management\n\nYou'll receive email notifications throughout the invoice lifecycle to help you stay on top of payments.\n\n**Notification schedule:**\n\n- **Invoice created** — \"Your Invoice is Ready\" email with amount, due date, and a link to view and pay the invoice\n- **7 days before due** — Upcoming invoice reminder\n- **2 days before due** — Payment reminder\n- **Due date** — Due today notice\n- **1 business day overdue** — Past due alert\n- **4+ business days overdue** — Overdue action required\n\n**Overdue blocking:**\n\nIf an invoice remains unpaid for more than 4 business days past the due date, the instance is automatically blocked. Blocked instances cannot process new transactions. An instance is unblocked only when no invoice is overdue for more than 4 business days. After paying the overdue invoice, the instance is unblocked automatically.\n\n---\n\n## Migration Notes\n\n- **Partner fee settlement model changed**: Partner fees are no longer sent per transaction. All partner fee earnings are accumulated and settled monthly via the invoice.\n- **Fee structure updated**: Fees are now structured per payment method and per blockchain network.\n- **Stripe and blockchain payments**: Each instance is linked to a Stripe customer. Invoices are created in Stripe with itemized line items and can be paid through Stripe or via blockchain with stablecoins.\n",{"title":1543,"description":1962},"changelog\u002F2026-03-06-new-billing-system","DTFULIh4nCDSwGvUNfVPw2SHWInxO9byMesW1QalwIA",{"id":1974,"title":1975,"author":7,"body":1976,"categories":7,"category":124,"categoryType":125,"date":2079,"description":2080,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":2081,"navigation":130,"path":2086,"rawbody":2087,"seo":2088,"stem":2089,"thumbnail":7,"__hash__":2090},"content\u002Fchangelog\u002F2026-04-03-faster-kyb-no-rfis-website-required.md","Faster KYB, No More RFIs, and Website Field Required",{"type":9,"value":1977,"toc":2072},[1978,1981,1983,2000,2002,2006,2013,2015,2019,2027,2030,2044,2046,2052,2064],[12,1979,1980],{},"Three changes to make compliance smoother and set expectations for an upcoming API requirement.",[16,1982,19],{"id":18},[21,1984,1985,1988,1991],{},[24,1986,1987],{},"KYB verification reduced from 3 business days to 1",[24,1989,1990],{},"No more RFIs — only documents listed in our API docs will ever be requested",[24,1992,1993,1996,1997,1999],{},[41,1994,1995],{},"Breaking change (May 2, 2026):"," the ",[58,1998,572],{}," field becomes required when creating a Business customer",[1583,2001],{},[16,2003,2005],{"id":2004},"kyb-verification-in-1-business-day","KYB Verification in 1 Business Day",[12,2007,2008,2009,2012],{},"KYB verification now completes within ",[41,2010,2011],{},"1 business day",", down from 3. No changes needed on your side — faster turnaround applies automatically to all new submissions.",[1583,2014],{},[16,2016,2018],{"id":2017},"no-more-rfis","No More RFIs",[12,2020,2021,2022,2026],{},"We will only ever request documents that are explicitly listed in our ",[46,2023,2025],{"href":2024},"\u002Fdocs","API documentation",". Ad-hoc Requests for Information (RFIs) are eliminated. If it's not in the docs, we won't ask for it.",[12,2028,2029],{},"The only two exceptions where an RFI may still be issued:",[21,2031,2032,2038],{},[24,2033,2034,2037],{},[41,2035,2036],{},"Unreadable or mismatched documents"," — when a submitted document cannot be processed by our KYC software (e.g., blurry scans, corrupted files) or when the document doesn't match the data provided (e.g., a proof of address missing the customer's name or showing a different address)",[24,2039,2040,2043],{},[41,2041,2042],{},"Nested payment scenarios"," — when we identify that the company being onboarded operates a nested payment structure",[1583,2045],{},[16,2047,2049,2051],{"id":2048},"website-field-required-for-business-customers",[58,2050,572],{}," Field Required for Business Customers",[12,2053,2054,2057,2058,2060,2061,2063],{},[41,2055,2056],{},"Effective May 2, 2026",", the ",[58,2059,572],{}," field will be ",[41,2062,1352],{}," when creating a Business customer. Requests without it will be rejected.",[12,2065,2066,2068,2069,2071],{},[41,2067,1103],{}," Update your integration to include the ",[58,2070,572],{}," field before May 2 to avoid failed requests.",{"title":117,"searchDepth":118,"depth":118,"links":2073},[2074,2075,2076,2077],{"id":18,"depth":118,"text":19},{"id":2004,"depth":118,"text":2005},{"id":2017,"depth":118,"text":2018},{"id":2048,"depth":118,"text":2078},"website Field Required for Business Customers","2026-04-03","KYB verification now takes 1 business day, document requests are limited to what's in our API docs, and the website field becomes required for Business customers on May 2.",{"excerpt":2082},{"type":9,"value":2083},[2084],[12,2085,1980],{},"\u002Fchangelog\u002F2026-04-03-faster-kyb-no-rfis-website-required","---\ntitle: Faster KYB, No More RFIs, and Website Field Required\ndescription: KYB verification now takes 1 business day, document requests are limited to what's in our API docs, and the website field becomes required for Business customers on May 2.\ndate: 2026-04-03\ncategory: Product Update\ncategoryType: update\nisChangelog: true\n---\n\nThree changes to make compliance smoother and set expectations for an upcoming API requirement.\n\n\u003C!--more-->\n\n## TL;DR\n\n- KYB verification reduced from 3 business days to 1\n- No more RFIs — only documents listed in our API docs will ever be requested\n- **Breaking change (May 2, 2026):** the `website` field becomes required when creating a Business customer\n\n---\n\n## KYB Verification in 1 Business Day\n\nKYB verification now completes within **1 business day**, down from 3. No changes needed on your side — faster turnaround applies automatically to all new submissions.\n\n---\n\n## No More RFIs\n\nWe will only ever request documents that are explicitly listed in our [API documentation](\u002Fdocs). Ad-hoc Requests for Information (RFIs) are eliminated. If it's not in the docs, we won't ask for it.\n\nThe only two exceptions where an RFI may still be issued:\n\n- **Unreadable or mismatched documents** — when a submitted document cannot be processed by our KYC software (e.g., blurry scans, corrupted files) or when the document doesn't match the data provided (e.g., a proof of address missing the customer's name or showing a different address)\n- **Nested payment scenarios** — when we identify that the company being onboarded operates a nested payment structure\n\n---\n\n## `website` Field Required for Business Customers\n\n**Effective May 2, 2026**, the `website` field will be **required** when creating a Business customer. Requests without it will be rejected.\n\n**Action required:** Update your integration to include the `website` field before May 2 to avoid failed requests.\n",{"title":1975,"description":2080},"changelog\u002F2026-04-03-faster-kyb-no-rfis-website-required","NqQiEKfeAjaUcY7yDxl1dkcxMBjtwfjIdvMi0RKwEkY",{"id":2092,"title":2093,"author":7,"body":2094,"categories":7,"category":124,"categoryType":125,"date":2278,"description":2279,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":2280,"navigation":130,"path":2285,"rawbody":2286,"seo":2287,"stem":2288,"thumbnail":7,"__hash__":2289},"content\u002Fchangelog\u002F2026-04-23-payments-expansion-ai-cli-passkey-enforcement.md","Payments Expansion, 1 Business Day SLA, BlindPay AI & CLI, and Passkey Enforcement",{"type":9,"value":2095,"toc":2271},[2096,2099,2101,2115,2117,2121,2124,2197,2199,2202,2212,2219,2221,2224,2232,2243,2245,2248,2251,2262],[12,2097,2098],{},"A recap of the payments expansion shipped over the last three months, a faster onboarding SLA, a new AI & CLI surface, and tighter account security with passkey enforcement.",[16,2100,19],{"id":18},[21,2102,2103,2106,2109,2112],{},[24,2104,2105],{},"ACH, Wire, RTP, and SWIFT updates",[24,2107,2108],{},"1 Business Day SLA",[24,2110,2111],{},"BlindPay AI & CLI",[24,2113,2114],{},"Passkey Enforcement",[1583,2116],{},[16,2118,2120],{"id":2119},"ach-wire-rtp-and-swift-updates","ACH, Wire, RTP, and SWIFT Updates",[12,2122,2123],{},"Over the last three months, we've been adding more providers and enhancing the payments experience at BlindPay. Here's a summary of what's available today:",[2125,2126,2127,2146],"table",{},[2128,2129,2130],"thead",{},[2131,2132,2133,2137,2140,2143],"tr",{},[2134,2135,2136],"th",{},"Method",[2134,2138,2139],{},"Payins (Memo)",[2134,2141,2142],{},"Payins (VA)",[2134,2144,2145],{},"Payouts",[2147,2148,2149,2162,2174,2185],"tbody",{},[2131,2150,2151,2155,2158,2160],{},[2152,2153,2154],"td",{},"ACH",[2152,2156,2157],{},"✅",[2152,2159,2157],{},[2152,2161,2157],{},[2131,2163,2164,2167,2169,2171],{},[2152,2165,2166],{},"Wire",[2152,2168,2157],{},[2152,2170,2157],{},[2152,2172,2173],{},"✅ (Only VA)",[2131,2175,2176,2179,2181,2183],{},[2152,2177,2178],{},"RTP",[2152,2180,2157],{},[2152,2182,2157],{},[2152,2184,2157],{},[2131,2186,2187,2190,2193,2195],{},[2152,2188,2189],{},"SWIFT",[2152,2191,2192],{},"✗",[2152,2194,2157],{},[2152,2196,2157],{},[1583,2198],{},[16,2200,2108],{"id":2201},"_1-business-day-sla",[12,2203,2204,2205,2208,2209,420],{},"We've made our onboarding process more seamless. No additional information beyond what's in the ",[46,2206,2207],{"href":2024},"documentation"," will be required, and the SLA has been reduced from ",[41,2210,2211],{},"3 to 1 business day",[12,2213,2214,2215,420],{},"If you're having trouble with the KYC\u002FKYB process, please reach out directly to ",[46,2216,2218],{"href":2217},"mailto:bernardo@blindpay.com","bernardo@blindpay.com",[1583,2220],{},[16,2222,2111],{"id":2223},"blindpay-ai-cli",[12,2225,2226,2227,2231],{},"We launched our new ",[46,2228,2230],{"href":2229},"\u002Fai","CLI and AI page",", where you can see all the tools we've been shipping to improve your integration experience.",[12,2233,2234,2235,2238,2239,420],{},"You can ask AI to run commands like ",[58,2236,2237],{},"blindpay customers list --json"," to debug or test things faster. ",[46,2240,2242],{"href":2241},"\u002Fblog\u002Fcli","Learn more here",[1583,2244],{},[16,2246,2114],{"id":2247},"passkey-enforcement",[12,2249,2250],{},"You can now require all team members using the BlindPay platform to enable passkeys. Once enforced, critical actions — such as initiating a payout, adding a bank account, creating wallets, or inviting new members — will require passkey verification.",[12,2252,2253,2254,2257,2258,2261],{},"Go to your instance > ",[41,2255,2256],{},"Settings"," > toggle the ",[41,2259,2260],{},"Enforce Passkey"," option.",[12,2263,2264],{},[2265,2266],"video",{"controls":130,"src":2267,"className":2268},"https:\u002F\u002Fpub-4fabf5dd55154f19a0384b16f2b816d9.r2.dev\u002Fpasskeys_compressed.mp4",[2269,2270],"w-full","rounded-lg",{"title":117,"searchDepth":118,"depth":118,"links":2272},[2273,2274,2275,2276,2277],{"id":18,"depth":118,"text":19},{"id":2119,"depth":118,"text":2120},{"id":2201,"depth":118,"text":2108},{"id":2223,"depth":118,"text":2111},{"id":2247,"depth":118,"text":2114},"2026-04-23","ACH, Wire, RTP, and SWIFT payin and payout coverage summarized in one table, onboarding SLA reduced to 1 business day, a new AI & CLI surface for faster integrations, and organization-wide passkey enforcement for critical actions.",{"excerpt":2281},{"type":9,"value":2282},[2283],[12,2284,2098],{},"\u002Fchangelog\u002F2026-04-23-payments-expansion-ai-cli-passkey-enforcement","---\ntitle: Payments Expansion, 1 Business Day SLA, BlindPay AI & CLI, and Passkey Enforcement\ndescription: ACH, Wire, RTP, and SWIFT payin and payout coverage summarized in one table, onboarding SLA reduced to 1 business day, a new AI & CLI surface for faster integrations, and organization-wide passkey enforcement for critical actions.\ndate: 2026-04-23\ncategory: Product Update\ncategoryType: update\nisChangelog: true\n---\n\nA recap of the payments expansion shipped over the last three months, a faster onboarding SLA, a new AI & CLI surface, and tighter account security with passkey enforcement.\n\n\u003C!--more-->\n\n## TL;DR\n\n- ACH, Wire, RTP, and SWIFT updates\n- 1 Business Day SLA\n- BlindPay AI & CLI\n- Passkey Enforcement\n\n---\n\n## ACH, Wire, RTP, and SWIFT Updates\n\nOver the last three months, we've been adding more providers and enhancing the payments experience at BlindPay. Here's a summary of what's available today:\n\n| Method | Payins (Memo) | Payins (VA) | Payouts      |\n| ------ | ------------- | ----------- | ------------ |\n| ACH    | ✅            | ✅          | ✅           |\n| Wire   | ✅            | ✅          | ✅ (Only VA) |\n| RTP    | ✅            | ✅          | ✅           |\n| SWIFT  | ✗             | ✅          | ✅           |\n\n---\n\n## 1 Business Day SLA\n\nWe've made our onboarding process more seamless. No additional information beyond what's in the [documentation](\u002Fdocs) will be required, and the SLA has been reduced from **3 to 1 business day**.\n\nIf you're having trouble with the KYC\u002FKYB process, please reach out directly to [bernardo@blindpay.com](mailto:bernardo@blindpay.com).\n\n---\n\n## BlindPay AI & CLI\n\nWe launched our new [CLI and AI page](\u002Fai), where you can see all the tools we've been shipping to improve your integration experience.\n\nYou can ask AI to run commands like `blindpay customers list --json` to debug or test things faster. [Learn more here](\u002Fblog\u002Fcli).\n\n---\n\n## Passkey Enforcement\n\nYou can now require all team members using the BlindPay platform to enable passkeys. Once enforced, critical actions — such as initiating a payout, adding a bank account, creating wallets, or inviting new members — will require passkey verification.\n\nGo to your instance > **Settings** > toggle the **Enforce Passkey** option.\n\n\u003Cvideo controls src=\"https:\u002F\u002Fpub-4fabf5dd55154f19a0384b16f2b816d9.r2.dev\u002Fpasskeys_compressed.mp4\" class=\"w-full rounded-lg\">\u003C\u002Fvideo>\n",{"title":2093,"description":2279},"changelog\u002F2026-04-23-payments-expansion-ai-cli-passkey-enforcement","BdIJogtoEelr1DUwxiAbftaial7pz0Mb_MolZ9oKqCM",{"id":2291,"title":2292,"author":7,"body":2293,"categories":7,"category":2634,"categoryType":2635,"date":2636,"description":2637,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":2638,"navigation":130,"path":2643,"rawbody":2644,"seo":2645,"stem":2646,"thumbnail":7,"__hash__":2647},"content\u002Fchangelog\u002F2026-04-24-audit-logs.md","Audit Logs",{"type":9,"value":2294,"toc":2626},[2295,2298,2300,2323,2327,2330,2430,2434,2437,2573,2577,2583,2586,2590,2593,2602,2612,2616],[12,2296,2297],{},"You can now see a history of actions that happen inside your instance, who did it, how, and from where.",[16,2299,19],{"id":18},[21,2301,2302,2305,2311,2314,2317,2320],{},[24,2303,2304],{},"Audit trail for actions on your instance",[24,2306,2307,2308],{},"Dashboard UI under ",[41,2309,2310],{},"Settings → Audit logs",[24,2312,2313],{},"API endpoints for programmatic access",[24,2315,2316],{},"Tracks actor identity, passkey usage, IP address, country, user agent, and metadata",[24,2318,2319],{},"Distinguishes between dashboard (user) and API key actions",[24,2321,2322],{},"Filterable by feature, operation, actor type, user ID, API key ID, and entity ID",[16,2324,2326],{"id":2325},"whats-logged","What's logged",[12,2328,2329],{},"Create, update, and delete operations across the platform are recorded:",[21,2331,2332,2338,2344,2349,2355,2360,2366,2371,2376,2381,2386,2391,2396,2402,2408,2413,2419,2425],{},[24,2333,2334,2337],{},[41,2335,2336],{},"Customers"," - create, update, delete",[24,2339,2340,2343],{},[41,2341,2342],{},"Bank accounts"," - create, delete",[24,2345,2346,2343],{},[41,2347,2348],{},"Blockchain wallets",[24,2350,2351,2354],{},[41,2352,2353],{},"Blockchain operations"," - asset trustlines, USDB minting, Solana delegation",[24,2356,2357,2359],{},[41,2358,400],{}," - create",[24,2361,2362,2365],{},[41,2363,2364],{},"Virtual accounts"," - create, update",[24,2367,2368,2343],{},[41,2369,2370],{},"Wallets",[24,2372,2373,2359],{},[41,2374,2375],{},"Payins",[24,2377,2378,2380],{},[41,2379,2145],{}," - create, update (document submission)",[24,2382,2383,2359],{},[41,2384,2385],{},"Transfers",[24,2387,2388,2359],{},[41,2389,2390],{},"Customer limit increases",[24,2392,2393,2343],{},[41,2394,2395],{},"API keys",[24,2397,2398,2401],{},[41,2399,2400],{},"Team members"," - update role, remove",[24,2403,2404,2407],{},[41,2405,2406],{},"Invites"," - create, accept, delete",[24,2409,2410,2343],{},[41,2411,2412],{},"Partner fees",[24,2414,2415,2418],{},[41,2416,2417],{},"Billing"," - update details, pay invoice, collect fees, portal session",[24,2420,2421,2424],{},[41,2422,2423],{},"Onboarding"," - every step from business details to completion",[24,2426,2427,2343],{},[41,2428,2429],{},"Webhook endpoints",[16,2431,2433],{"id":2432},"what-each-log-captures","What each log captures",[12,2435,2436],{},"Every audit log entry includes:",[2125,2438,2439,2449],{},[2128,2440,2441],{},[2131,2442,2443,2446],{},[2134,2444,2445],{},"Field",[2134,2447,2448],{},"Description",[2147,2450,2451,2461,2478,2488,2505,2523,2533,2543,2553,2563],{},[2131,2452,2453,2458],{},[2152,2454,2455],{},[41,2456,2457],{},"Actor",[2152,2459,2460],{},"The user or API key that performed the action",[2131,2462,2463,2468],{},[2152,2464,2465],{},[41,2466,2467],{},"Actor type",[2152,2469,2470,2473,2474,2477],{},[58,2471,2472],{},"user"," (dashboard) or ",[58,2475,2476],{},"api_key"," (programmatic)",[2131,2479,2480,2485],{},[2152,2481,2482],{},[41,2483,2484],{},"Passkey",[2152,2486,2487],{},"Whether the action was verified with a passkey",[2131,2489,2490,2495],{},[2152,2491,2492],{},[41,2493,2494],{},"Feature",[2152,2496,2497,2498,88,2501,2504],{},"The area of the platform (e.g. ",[58,2499,2500],{},"bank_account",[58,2502,2503],{},"payout",")",[2131,2506,2507,2512],{},[2152,2508,2509],{},[41,2510,2511],{},"Operation",[2152,2513,2514,88,2517,2519,2520],{},[58,2515,2516],{},"create",[58,2518,125],{},", or ",[58,2521,2522],{},"delete",[2131,2524,2525,2530],{},[2152,2526,2527],{},[41,2528,2529],{},"Entity",[2152,2531,2532],{},"The type and ID of the affected resource",[2131,2534,2535,2540],{},[2152,2536,2537],{},[41,2538,2539],{},"IP address",[2152,2541,2542],{},"Origin IP of the request",[2131,2544,2545,2550],{},[2152,2546,2547],{},[41,2548,2549],{},"Country",[2152,2551,2552],{},"Country derived from the request",[2131,2554,2555,2560],{},[2152,2556,2557],{},[41,2558,2559],{},"User agent",[2152,2561,2562],{},"Browser or SDK making the request",[2131,2564,2565,2570],{},[2152,2566,2567],{},[41,2568,2569],{},"Metadata",[2152,2571,2572],{},"Additional context specific to the action",[16,2574,2576],{"id":2575},"dashboard","Dashboard",[12,2578,2579,2580,2582],{},"Navigate to ",[41,2581,2310],{}," to browse your instance's activity. Click any entry to open the detail pane with the full breakdown: actor info, request metadata, and action-specific context.",[12,2584,2585],{},"Use the filters to narrow down by feature, operation, actor type, user ID, API key ID, or entity ID.",[16,2587,2589],{"id":2588},"api","API",[12,2591,2592],{},"Two new endpoints are available:",[2594,2595,2600],"pre",{"className":2596,"code":2598,"language":2599},[2597],"language-text","GET \u002Fv1\u002Finstances\u002F{instance_id}\u002Faudit-logs\nGET \u002Fv1\u002Finstances\u002F{instance_id}\u002Faudit-logs\u002F{id}\n","text",[58,2601,2598],{"__ignoreMap":117},[12,2603,2604,2605,80,2608,2611],{},"The list endpoint returns a paginated list of audit logs for your instance. It supports cursor-based pagination and the same filters available in the dashboard, plus date range filtering with ",[58,2606,2607],{},"start_date",[58,2609,2610],{},"end_date",". The detail endpoint returns a single audit log entry by ID.",[16,2613,2615],{"id":2614},"permissions","Permissions",[12,2617,2618,2619,80,2622,2625],{},"Only ",[41,2620,2621],{},"owner",[41,2623,2624],{},"admin"," roles can view audit logs.",{"title":117,"searchDepth":118,"depth":118,"links":2627},[2628,2629,2630,2631,2632,2633],{"id":18,"depth":118,"text":19},{"id":2325,"depth":118,"text":2326},{"id":2432,"depth":118,"text":2433},{"id":2575,"depth":118,"text":2576},{"id":2588,"depth":118,"text":2589},{"id":2614,"depth":118,"text":2615},"New Feature","feature","2026-04-24","Track actions across your instance with audit logs. See who did what, when, from where, and whether a passkey was used, from the dashboard or the API.",{"excerpt":2639},{"type":9,"value":2640},[2641],[12,2642,2297],{},"\u002Fchangelog\u002F2026-04-24-audit-logs","---\ntitle: Audit Logs\ndescription: Track actions across your instance with audit logs. See who did what, when, from where, and whether a passkey was used, from the dashboard or the API.\ndate: 2026-04-24\ncategory: New Feature\ncategoryType: feature\nisChangelog: true\n---\n\nYou can now see a history of actions that happen inside your instance, who did it, how, and from where.\n\n\u003C!--more-->\n\n## TL;DR\n\n- Audit trail for actions on your instance\n- Dashboard UI under **Settings → Audit logs**\n- API endpoints for programmatic access\n- Tracks actor identity, passkey usage, IP address, country, user agent, and metadata\n- Distinguishes between dashboard (user) and API key actions\n- Filterable by feature, operation, actor type, user ID, API key ID, and entity ID\n\n## What's logged\n\nCreate, update, and delete operations across the platform are recorded:\n\n- **Customers** - create, update, delete\n- **Bank accounts** - create, delete\n- **Blockchain wallets** - create, delete\n- **Blockchain operations** - asset trustlines, USDB minting, Solana delegation\n- **Offramp wallets** - create\n- **Virtual accounts** - create, update\n- **Wallets** - create, delete\n- **Payins** - create\n- **Payouts** - create, update (document submission)\n- **Transfers** - create\n- **Customer limit increases** - create\n- **API keys** - create, delete\n- **Team members** - update role, remove\n- **Invites** - create, accept, delete\n- **Partner fees** - create, delete\n- **Billing** - update details, pay invoice, collect fees, portal session\n- **Onboarding** - every step from business details to completion\n- **Webhook endpoints** - create, delete\n\n## What each log captures\n\nEvery audit log entry includes:\n\n| Field | Description |\n|-------|-------------|\n| **Actor** | The user or API key that performed the action |\n| **Actor type** | `user` (dashboard) or `api_key` (programmatic) |\n| **Passkey** | Whether the action was verified with a passkey |\n| **Feature** | The area of the platform (e.g. `bank_account`, `payout`) |\n| **Operation** | `create`, `update`, or `delete` |\n| **Entity** | The type and ID of the affected resource |\n| **IP address** | Origin IP of the request |\n| **Country** | Country derived from the request |\n| **User agent** | Browser or SDK making the request |\n| **Metadata** | Additional context specific to the action |\n\n## Dashboard\n\nNavigate to **Settings → Audit logs** to browse your instance's activity. Click any entry to open the detail pane with the full breakdown: actor info, request metadata, and action-specific context.\n\nUse the filters to narrow down by feature, operation, actor type, user ID, API key ID, or entity ID.\n\n## API\n\nTwo new endpoints are available:\n\n```\nGET \u002Fv1\u002Finstances\u002F{instance_id}\u002Faudit-logs\nGET \u002Fv1\u002Finstances\u002F{instance_id}\u002Faudit-logs\u002F{id}\n```\n\nThe list endpoint returns a paginated list of audit logs for your instance. It supports cursor-based pagination and the same filters available in the dashboard, plus date range filtering with `start_date` and `end_date`. The detail endpoint returns a single audit log entry by ID.\n\n## Permissions\n\nOnly **owner** and **admin** roles can view audit logs.\n",{"title":2292,"description":2637},"changelog\u002F2026-04-24-audit-logs","qnsRup-Bw5sjaHF3yac0ggpk-kx0NFPs82CDViZVH8E",{"id":2649,"title":2650,"author":7,"body":2651,"categories":7,"category":2732,"categoryType":125,"date":2733,"description":2734,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":2735,"navigation":130,"path":2740,"rawbody":2741,"seo":2742,"stem":2743,"thumbnail":7,"__hash__":2744},"content\u002Fchangelog\u002F2026-05-15-stellar-wallet-rotation-and-testnet-fix.md","Stellar Wallet Rotation and Testnet USDB Fix",{"type":9,"value":2652,"toc":2726},[2653,2656,2658,2669,2673,2682,2685,2689,2696,2700,2706,2711,2723],[12,2654,2655],{},"Two Stellar wallet rotations and a bug fix that affected development-instance customers on Stellar testnet.",[16,2657,19],{"id":18},[21,2659,2660,2663,2666],{},[24,2661,2662],{},"Fixed USDB issuer mismatch on Stellar testnet trustline and mint endpoints",[24,2664,2665],{},"Rotated the BlindPay operational wallet on Stellar mainnet",[24,2667,2668],{},"Rotated the USDB issuer on Stellar testnet (action required for development instances)",[16,2670,2672],{"id":2671},"bug-fix-usdb-issuer-mismatch-on-stellar-testnet","Bug fix: USDB issuer mismatch on Stellar testnet",[12,2674,76,2675,80,2678,2681],{},[58,2676,2677],{},"POST \u002Fcreate-asset-trustline",[58,2679,2680],{},"POST \u002Fmint-usdb-stellar"," endpoints were referencing a different USDB issuer than the one used by payins and payouts. This caused development-instance customers to see different tokens depending on the operation. Both endpoints now use the same issuer as all other operations.",[12,2683,2684],{},"No API contract changes — request and response schemas remain the same.",[16,2686,2688],{"id":2687},"mainnet-operational-wallet-rotated","Mainnet operational wallet rotated",[12,2690,2691,2692,2695],{},"The BlindPay treasury wallet on Stellar mainnet has been rotated to ",[58,2693,2694],{},"GCOSSQDM2SWMHRP7CDBOLL2V45NHCRLUWUCEHPPBA2ABCOOLPOLZKIHE",". This wallet receives payout crypto and sends payin crypto on Stellar mainnet. No action is required from customers — the system already uses the new wallet.",[16,2697,2699],{"id":2698},"testnet-usdb-issuer-rotated","Testnet USDB issuer rotated",[12,2701,2702,2703,420],{},"The USDB asset issuer on Stellar testnet has been rotated to ",[58,2704,2705],{},"GCQSSIMOW5OCGULZATDXKU5MOJBOMFX6G65X6CXZDQ7AIB3SKFUZ67NX",[12,2707,2708],{},[41,2709,2710],{},"Action required for development instances on Stellar testnet:",[1181,2712,2713,2718],{},[24,2714,2715,2716],{},"Create a new USDB trustline via ",[58,2717,2677],{},[24,2719,2720,2721],{},"Mint new USDB via ",[58,2722,2680],{},[12,2724,2725],{},"Old USDB balances from the previous issuer are orphaned and no longer recognized by the system.",{"title":117,"searchDepth":118,"depth":118,"links":2727},[2728,2729,2730,2731],{"id":18,"depth":118,"text":19},{"id":2671,"depth":118,"text":2672},{"id":2687,"depth":118,"text":2688},{"id":2698,"depth":118,"text":2699},"Infrastructure","2026-05-15","Rotated the Stellar mainnet operational wallet and testnet USDB issuer, and fixed a token mismatch bug where trustline and mint endpoints used a different USDB issuer than payins and payouts on Stellar testnet.",{"excerpt":2736},{"type":9,"value":2737},[2738],[12,2739,2655],{},"\u002Fchangelog\u002F2026-05-15-stellar-wallet-rotation-and-testnet-fix","---\ntitle: Stellar Wallet Rotation and Testnet USDB Fix\ndescription: Rotated the Stellar mainnet operational wallet and testnet USDB issuer, and fixed a token mismatch bug where trustline and mint endpoints used a different USDB issuer than payins and payouts on Stellar testnet.\ndate: 2026-05-15\ncategory: Infrastructure\ncategoryType: update\nisChangelog: true\n---\n\nTwo Stellar wallet rotations and a bug fix that affected development-instance customers on Stellar testnet.\n\n\u003C!--more-->\n\n## TL;DR\n\n- Fixed USDB issuer mismatch on Stellar testnet trustline and mint endpoints\n- Rotated the BlindPay operational wallet on Stellar mainnet\n- Rotated the USDB issuer on Stellar testnet (action required for development instances)\n\n## Bug fix: USDB issuer mismatch on Stellar testnet\n\nThe `POST \u002Fcreate-asset-trustline` and `POST \u002Fmint-usdb-stellar` endpoints were referencing a different USDB issuer than the one used by payins and payouts. This caused development-instance customers to see different tokens depending on the operation. Both endpoints now use the same issuer as all other operations.\n\nNo API contract changes — request and response schemas remain the same.\n\n## Mainnet operational wallet rotated\n\nThe BlindPay treasury wallet on Stellar mainnet has been rotated to `GCOSSQDM2SWMHRP7CDBOLL2V45NHCRLUWUCEHPPBA2ABCOOLPOLZKIHE`. This wallet receives payout crypto and sends payin crypto on Stellar mainnet. No action is required from customers — the system already uses the new wallet.\n\n## Testnet USDB issuer rotated\n\nThe USDB asset issuer on Stellar testnet has been rotated to `GCQSSIMOW5OCGULZATDXKU5MOJBOMFX6G65X6CXZDQ7AIB3SKFUZ67NX`.\n\n**Action required for development instances on Stellar testnet:**\n\n1. Create a new USDB trustline via `POST \u002Fcreate-asset-trustline`\n2. Mint new USDB via `POST \u002Fmint-usdb-stellar`\n\nOld USDB balances from the previous issuer are orphaned and no longer recognized by the system.\n",{"title":2650,"description":2734},"changelog\u002F2026-05-15-stellar-wallet-rotation-and-testnet-fix","tosSKNqaGiKIAEZYsVNEa-gKjHXlKyEZ0sGtjERFFro",{"id":2746,"title":2747,"author":7,"body":2748,"categories":7,"category":124,"categoryType":125,"date":2830,"description":2831,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":2832,"navigation":130,"path":2837,"rawbody":2838,"seo":2839,"stem":2840,"thumbnail":7,"__hash__":2841},"content\u002Fchangelog\u002F2026-05-22-rfi-apis-audit-logs-and-ted-payouts-brazil.md","RFI APIs, Audit Logs, and TED Payouts in Brazil",{"type":9,"value":2749,"toc":2824},[2750,2753,2755,2775,2779,2782,2789,2792,2798,2804,2808,2811],[12,2751,2752],{},"May's product updates: compliance review goes fully programmatic, every sensitive action is traceable, and Brazilian payouts gain a high-value rail.",[16,2754,19],{"id":18},[21,2756,2757,2763,2769],{},[24,2758,2759,2762],{},[41,2760,2761],{},"RFI APIs:"," programmatic Request for Information flow",[24,2764,2765,2768],{},[41,2766,2767],{},"Audit Logs:"," full visibility into sensitive team actions",[24,2770,2771,2774],{},[41,2772,2773],{},"TED:"," high-volume payouts in Brazil",[16,2776,2778],{"id":2777},"rfi-apis","RFI APIs",[12,2780,2781],{},"Compliance review is now fully programmatic. You no longer need to email supporting documents when a customer requires additional information. Once you create a customer, we will notify you by email and webhook whenever a Request for Information (RFI) is opened, and your team can respond directly through the API.",[12,2783,2784,2785,265],{},"This eliminates manual handoffs, shortens KYC\u002FKYB turnaround times, and keeps the entire review trail inside your own systems. ",[46,2786,2788],{"href":2787},"\u002Fdocs\u002Fessentials\u002Frfi","Read the RFI documentation",[16,2790,2292],{"id":2791},"audit-logs",[12,2793,2794,2795,2797],{},"Every sensitive action performed by members of your organization is now recorded in a dedicated audit trail, accessible under ",[41,2796,2310],{},". Each entry captures the actor, the affected resource, IP address, and a UTC timestamp, providing the traceability that internal and external auditors expect.",[12,2799,2800,2801,420],{},"Audit Logs are part of our ongoing security commitment and are designed to support SOC 2, ISO 27001, and customer-led audit workflows. ",[46,2802,2803],{"href":2643},"Read more in the Audit Logs changelog",[16,2805,2807],{"id":2806},"ted-payouts-in-brazil","TED Payouts in Brazil",[12,2809,2810],{},"BlindPay now supports TED (Transferência Eletrônica Disponível) as a payout rail in Brazil, complementing our existing PIX coverage. TED is the preferred rail for high-value, business-to-business transactions and enables you to settle larger volumes with the same instance configuration you already use today.",[12,2812,2813,2814,2818,2819,2823],{},"TED is available as a selectable bank account type and as a payin method. Review the ",[46,2815,2817],{"href":2816},"\u002Fdocs\u002Fessentials\u002Fpayouts","Payouts documentation"," and the ",[46,2820,2822],{"href":2821},"\u002Fdocs\u002Fessentials\u002Fbank-accounts","Bank Accounts reference"," for setup details.",{"title":117,"searchDepth":118,"depth":118,"links":2825},[2826,2827,2828,2829],{"id":18,"depth":118,"text":19},{"id":2777,"depth":118,"text":2778},{"id":2791,"depth":118,"text":2292},{"id":2806,"depth":118,"text":2807},"2026-05-22","A programmatic Request for Information flow, a dedicated audit trail for sensitive team actions, and TED as a new payout rail in Brazil for high-volume transactions.",{"excerpt":2833},{"type":9,"value":2834},[2835],[12,2836,2752],{},"\u002Fchangelog\u002F2026-05-22-rfi-apis-audit-logs-and-ted-payouts-brazil","---\ntitle: RFI APIs, Audit Logs, and TED Payouts in Brazil\ndescription: A programmatic Request for Information flow, a dedicated audit trail for sensitive team actions, and TED as a new payout rail in Brazil for high-volume transactions.\ndate: 2026-05-22\ncategory: Product Update\ncategoryType: update\nisChangelog: true\n---\n\nMay's product updates: compliance review goes fully programmatic, every sensitive action is traceable, and Brazilian payouts gain a high-value rail.\n\n\u003C!--more-->\n\n## TL;DR\n\n- **RFI APIs:** programmatic Request for Information flow\n- **Audit Logs:** full visibility into sensitive team actions\n- **TED:** high-volume payouts in Brazil\n\n## RFI APIs\n\nCompliance review is now fully programmatic. You no longer need to email supporting documents when a customer requires additional information. Once you create a customer, we will notify you by email and webhook whenever a Request for Information (RFI) is opened, and your team can respond directly through the API.\n\nThis eliminates manual handoffs, shortens KYC\u002FKYB turnaround times, and keeps the entire review trail inside your own systems. [Read the RFI documentation](\u002Fdocs\u002Fessentials\u002Frfi) to get started.\n\n## Audit Logs\n\nEvery sensitive action performed by members of your organization is now recorded in a dedicated audit trail, accessible under **Settings → Audit logs**. Each entry captures the actor, the affected resource, IP address, and a UTC timestamp, providing the traceability that internal and external auditors expect.\n\nAudit Logs are part of our ongoing security commitment and are designed to support SOC 2, ISO 27001, and customer-led audit workflows. [Read more in the Audit Logs changelog](\u002Fchangelog\u002F2026-04-24-audit-logs).\n\n## TED Payouts in Brazil\n\nBlindPay now supports TED (Transferência Eletrônica Disponível) as a payout rail in Brazil, complementing our existing PIX coverage. TED is the preferred rail for high-value, business-to-business transactions and enables you to settle larger volumes with the same instance configuration you already use today.\n\nTED is available as a selectable bank account type and as a payin method. Review the [Payouts documentation](\u002Fdocs\u002Fessentials\u002Fpayouts) and the [Bank Accounts reference](\u002Fdocs\u002Fessentials\u002Fbank-accounts) for setup details.\n",{"title":2747,"description":2831},"changelog\u002F2026-05-22-rfi-apis-audit-logs-and-ted-payouts-brazil","GG_aUvhl9sYnlrU_BBv_zzGHHE0DiXME8LNsrtEO-TA",{"id":2843,"title":2844,"author":7,"body":2845,"categories":7,"category":2634,"categoryType":2635,"date":2993,"description":2994,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":2995,"navigation":130,"path":3000,"rawbody":3001,"seo":3002,"stem":3003,"thumbnail":7,"__hash__":3004},"content\u002Fchangelog\u002F2026-05-29-sepa-eur-payouts.md","SEPA EUR Payouts",{"type":9,"value":2846,"toc":2986},[2847,2850,2852,2875,2879,2882,2897,2901,2933,2937,2940,2943,2950,2953,2979,2983],[12,2848,2849],{},"You can now send USDC and have your receiver get EUR across the SEPA zone. USDC moves on Polygon or Ethereum, and EUR lands in the receiver's IBAN within 5 to 30 minutes.",[16,2851,19],{"id":18},[21,2853,2854,2857,2860,2863,2866,2869,2872],{},[24,2855,2856],{},"Send USDC and pay receivers in EUR across 40 SEPA-zone countries",[24,2858,2859],{},"USDC on Polygon or Ethereum",[24,2861,2862],{},"Minimum payout: 11 USDC",[24,2864,2865],{},"Per-payout maximum: $100,000 when the receiver is an individual, $300,000 when the receiver is a business",[24,2867,2868],{},"Settlement in 5 to 30 minutes after we receive your USDC",[24,2870,2871],{},"Supports B2B, B2C, C2B, and C2C use cases. 7 countries are C2C-only (see below)",[24,2873,2874],{},"Same payout API as every other rail. Create a SEPA bank account, request a quote, execute the payout",[16,2876,2878],{"id":2877},"how-it-works","How it works",[12,2880,2881],{},"The flow is identical to your existing payouts:",[1181,2883,2884,2891,2894],{},[24,2885,2886,2887,2890],{},"Create a bank account with ",[58,2888,2889],{},"type: \"sepa\"",", the receiver's IBAN, BIC, full name, and address. The country of the IBAN determines which use cases are available (see the C2C-only list below).",[24,2892,2893],{},"Request a quote for the USDC amount you want to send. We return the EUR your receiver will get.",[24,2895,2896],{},"Execute the payout. EUR settles to the receiver's IBAN within 5 to 30 minutes after we receive your USDC.",[16,2898,2900],{"id":2899},"rules","Rules",[21,2902,2903,2909,2915,2921,2927],{},[24,2904,2905,2908],{},[41,2906,2907],{},"Minimum",": 11 USDC per payout.",[24,2910,2911,2914],{},[41,2912,2913],{},"Per-payout maximum",": $100,000 when the receiver is an individual (B2C, C2C) and $300,000 when the receiver is a business (B2B, C2B).",[24,2916,2917,2920],{},[41,2918,2919],{},"No fixed EUR amounts",": quotes take a USDC amount and return the EUR your receiver gets.",[24,2922,2923,2926],{},[41,2924,2925],{},"Networks",": USDC on Polygon or Ethereum mainnet. Native USDC only.",[24,2928,2929,2932],{},[41,2930,2931],{},"Receiver country",": must be one of the 40 SEPA-zone countries listed below.",[16,2934,2936],{"id":2935},"supported-countries","Supported countries",[12,2938,2939],{},"All 40 countries below support B2B, B2C, C2B, and C2C use cases unless flagged:",[12,2941,2942],{},"Andorra (AD), Albania (AL), Austria (AT)*, Belgium (BE), Bulgaria (BG), Switzerland (CH), Cyprus (CY), Czech Republic (CZ), Germany (DE), Denmark (DK), Estonia (EE)*, Spain (ES), Finland (FI)*, France (FR)*, United Kingdom (GB), Greece (GR), Croatia (HR), Hungary (HU), Ireland (IE), Iceland (IS), Italy (IT), Liechtenstein (LI), Lithuania (LT)*, Luxembourg (LU), Latvia (LV), Monaco (MC), Moldova (MD), Montenegro (ME), North Macedonia (MK), Malta (MT), Netherlands (NL), Norway (NO)*, Poland (PL), Portugal (PT)*, Romania (RO), Sweden (SE), Slovenia (SI), Slovakia (SK), San Marino (SM), Vatican City (VA).",[12,2944,2945,2946,2949],{},"* ",[41,2947,2948],{},"C2C-only countries",": Austria (AT), Estonia (EE), Finland (FI), France (FR), Lithuania (LT), Norway (NO), and Portugal (PT) only accept C2C (individual to individual) payouts. Sending to a business beneficiary in these countries (B2B, C2B) or sending from a business sender (B2C) is not supported.",[12,2951,2952],{},"The use case is derived from the sender (your customer) and the receiver:",[21,2954,2955,2961,2967,2973],{},[24,2956,2957,2960],{},[41,2958,2959],{},"B2B",": business sender to business beneficiary",[24,2962,2963,2966],{},[41,2964,2965],{},"B2C",": business sender to individual beneficiary",[24,2968,2969,2972],{},[41,2970,2971],{},"C2B",": individual sender to business beneficiary",[24,2974,2975,2978],{},[41,2976,2977],{},"C2C",": individual sender to individual beneficiary",[16,2980,2982],{"id":2981},"get-started","Get started",[12,2984,2985],{},"If your account already has KYC approved, SEPA is available immediately, no extra activation. Create a SEPA bank account from the dashboard or the API, and you're ready to send your first payout.",{"title":117,"searchDepth":118,"depth":118,"links":2987},[2988,2989,2990,2991,2992],{"id":18,"depth":118,"text":19},{"id":2877,"depth":118,"text":2878},{"id":2899,"depth":118,"text":2900},{"id":2935,"depth":118,"text":2936},{"id":2981,"depth":118,"text":2982},"2026-05-29","Send USDC and have your receiver get EUR in any SEPA-zone bank account across 40 countries, with settlement in 5 to 30 minutes. Supports B2B, B2C, C2B, and C2C use cases.",{"excerpt":2996},{"type":9,"value":2997},[2998],[12,2999,2849],{},"\u002Fchangelog\u002F2026-05-29-sepa-eur-payouts","---\ntitle: SEPA EUR Payouts\ndescription: Send USDC and have your receiver get EUR in any SEPA-zone bank account across 40 countries, with settlement in 5 to 30 minutes. Supports B2B, B2C, C2B, and C2C use cases.\ndate: 2026-05-29\ncategory: New Feature\ncategoryType: feature\nisChangelog: true\n---\n\nYou can now send USDC and have your receiver get EUR across the SEPA zone. USDC moves on Polygon or Ethereum, and EUR lands in the receiver's IBAN within 5 to 30 minutes.\n\n\u003C!--more-->\n\n## TL;DR\n\n- Send USDC and pay receivers in EUR across 40 SEPA-zone countries\n- USDC on Polygon or Ethereum\n- Minimum payout: 11 USDC\n- Per-payout maximum: $100,000 when the receiver is an individual, $300,000 when the receiver is a business\n- Settlement in 5 to 30 minutes after we receive your USDC\n- Supports B2B, B2C, C2B, and C2C use cases. 7 countries are C2C-only (see below)\n- Same payout API as every other rail. Create a SEPA bank account, request a quote, execute the payout\n\n## How it works\n\nThe flow is identical to your existing payouts:\n\n1. Create a bank account with `type: \"sepa\"`, the receiver's IBAN, BIC, full name, and address. The country of the IBAN determines which use cases are available (see the C2C-only list below).\n2. Request a quote for the USDC amount you want to send. We return the EUR your receiver will get.\n3. Execute the payout. EUR settles to the receiver's IBAN within 5 to 30 minutes after we receive your USDC.\n\n## Rules\n\n- **Minimum**: 11 USDC per payout.\n- **Per-payout maximum**: $100,000 when the receiver is an individual (B2C, C2C) and $300,000 when the receiver is a business (B2B, C2B).\n- **No fixed EUR amounts**: quotes take a USDC amount and return the EUR your receiver gets.\n- **Networks**: USDC on Polygon or Ethereum mainnet. Native USDC only.\n- **Receiver country**: must be one of the 40 SEPA-zone countries listed below.\n\n## Supported countries\n\nAll 40 countries below support B2B, B2C, C2B, and C2C use cases unless flagged:\n\nAndorra (AD), Albania (AL), Austria (AT)\\*, Belgium (BE), Bulgaria (BG), Switzerland (CH), Cyprus (CY), Czech Republic (CZ), Germany (DE), Denmark (DK), Estonia (EE)\\*, Spain (ES), Finland (FI)\\*, France (FR)\\*, United Kingdom (GB), Greece (GR), Croatia (HR), Hungary (HU), Ireland (IE), Iceland (IS), Italy (IT), Liechtenstein (LI), Lithuania (LT)\\*, Luxembourg (LU), Latvia (LV), Monaco (MC), Moldova (MD), Montenegro (ME), North Macedonia (MK), Malta (MT), Netherlands (NL), Norway (NO)\\*, Poland (PL), Portugal (PT)\\*, Romania (RO), Sweden (SE), Slovenia (SI), Slovakia (SK), San Marino (SM), Vatican City (VA).\n\n\\* **C2C-only countries**: Austria (AT), Estonia (EE), Finland (FI), France (FR), Lithuania (LT), Norway (NO), and Portugal (PT) only accept C2C (individual to individual) payouts. Sending to a business beneficiary in these countries (B2B, C2B) or sending from a business sender (B2C) is not supported.\n\nThe use case is derived from the sender (your customer) and the receiver:\n\n- **B2B**: business sender to business beneficiary\n- **B2C**: business sender to individual beneficiary\n- **C2B**: individual sender to business beneficiary\n- **C2C**: individual sender to individual beneficiary\n\n## Get started\n\nIf your account already has KYC approved, SEPA is available immediately, no extra activation. Create a SEPA bank account from the dashboard or the API, and you're ready to send your first payout.\n",{"title":2844,"description":2994},"changelog\u002F2026-05-29-sepa-eur-payouts","rCiDvlhODGgsVWC0Ys6HPqS5O7lRUwFBx0kNFspWXyM",{"id":3006,"title":3007,"author":7,"body":3008,"categories":7,"category":3751,"categoryType":125,"date":3752,"description":3753,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":3754,"navigation":130,"path":3759,"rawbody":3760,"seo":3761,"stem":3762,"thumbnail":7,"__hash__":3763},"content\u002Fchangelog\u002F2026-06-04-customers-rename.md","\"Receivers\" renamed to \"Customers\"",{"type":9,"value":3009,"toc":3733},[3010,3013,3015,3066,3070,3079,3085,3088,3092,3111,3171,3188,3194,3198,3201,3229,3244,3259,3263,3380,3389,3407,3410,3442,3446,3491,3495,3552,3556,3562,3594,3600,3604,3607,3646,3650,3654,3675,3679,3682,3686,3694,3698,3709,3713,3729],[12,3011,3012],{},"We're renaming \"Receivers\" to \"Customers\" across the entire BlindPay platform: API endpoints, SDKs, documentation, and dashboard.",[16,3014,19],{"id":18},[21,3016,3017,3028,3039,3048,3055],{},[24,3018,3019,3020,3023,3024,3027],{},"All ",[58,3021,3022],{},"\u002Freceivers"," endpoints now have ",[58,3025,3026],{},"\u002Fcustomers"," equivalents",[24,3029,3030,3031,80,3033,3035,3036],{},"Both ",[58,3032,3022],{},[58,3034,3026],{}," paths work identically through ",[41,3037,3038],{},"July 3, 2026",[24,3040,3041,3042,3044,3045],{},"After that date, ",[58,3043,3022],{}," endpoints return ",[58,3046,3047],{},"301 Moved Permanently",[24,3049,3050,3051,3054],{},"IDs stay the same (",[58,3052,3053],{},"re_"," prefix), no data migration needed",[24,3056,3057,3058,3061,3062,3065],{},"SDKs add a ",[58,3059,3060],{},"customers"," accessor to their current majors and ",[58,3063,3064],{},"receivers"," is deprecated alongside, no import changes required",[16,3067,3069],{"id":3068},"what-changed","What changed",[12,3071,3072,3073,3075,3076,3078],{},"Every API endpoint that previously used ",[58,3074,3022],{}," in its path now has a ",[58,3077,3026],{}," equivalent:",[2594,3080,3083],{"className":3081,"code":3082,"language":2599},[2597],"GET    \u002Fv1\u002Finstances\u002F{instance_id}\u002Freceivers                →  GET    \u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers\nPOST   \u002Fv1\u002Finstances\u002F{instance_id}\u002Freceivers                →  POST   \u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers\nGET    \u002Fv1\u002Finstances\u002F{instance_id}\u002Freceivers\u002F{receiver_id}  →  GET    \u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers\u002F{customer_id}\nPUT    \u002Fv1\u002Finstances\u002F{instance_id}\u002Freceivers\u002F{receiver_id}  →  PUT    \u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers\u002F{customer_id}\nDELETE \u002Fv1\u002Finstances\u002F{instance_id}\u002Freceivers\u002F{receiver_id}  →  DELETE \u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers\u002F{customer_id}\n",[58,3084,3082],{"__ignoreMap":117},[12,3086,3087],{},"This applies to all sub-resources too: bank accounts, wallets, virtual accounts, blockchain wallets, offramp wallets, and limit increases.",[16,3089,3091],{"id":3090},"response-changes","Response changes",[12,3093,3094,3095,3097,3098,3100,3101,3103,3104,3106,3107,3110],{},"During the transition period, every customer record returned by either ",[58,3096,3026],{}," or ",[58,3099,3022],{}," carries a ",[58,3102,108],{}," alias of its primary key. The underlying ID still uses the ",[58,3105,3053],{}," prefix and remains in the ",[58,3108,3109],{},"id"," field:",[2594,3112,3116],{"className":3113,"code":3114,"language":3115,"meta":117,"style":117},"language-json shiki shiki-themes github-light","{\n  \"id\": \"re_abc123456789\",\n  \"customer_id\": \"re_abc123456789\",\n  \"first_name\": \"Alice\"\n}\n","json",[58,3117,3118,3127,3143,3154,3165],{"__ignoreMap":117},[3119,3120,3123],"span",{"class":3121,"line":3122},"line",1,[3119,3124,3126],{"class":3125},"sgsFI","{\n",[3119,3128,3129,3133,3136,3140],{"class":3121,"line":118},[3119,3130,3132],{"class":3131},"sYu0t","  \"id\"",[3119,3134,3135],{"class":3125},": ",[3119,3137,3139],{"class":3138},"sYBdl","\"re_abc123456789\"",[3119,3141,3142],{"class":3125},",\n",[3119,3144,3145,3148,3150,3152],{"class":3121,"line":1417},[3119,3146,3147],{"class":3131},"  \"customer_id\"",[3119,3149,3135],{"class":3125},[3119,3151,3139],{"class":3138},[3119,3153,3142],{"class":3125},[3119,3155,3157,3160,3162],{"class":3121,"line":3156},4,[3119,3158,3159],{"class":3131},"  \"first_name\"",[3119,3161,3135],{"class":3125},[3119,3163,3164],{"class":3138},"\"Alice\"\n",[3119,3166,3168],{"class":3121,"line":3167},5,[3119,3169,3170],{"class":3125},"}\n",[12,3172,3173,3174,80,3177,3179,3180,3183,3184,3187],{},"Payouts and payins that reference a customer expose both ",[58,3175,3176],{},"receiver_id",[58,3178,108],{}," foreign-key fields during the transition; either accepts the same ",[58,3181,3182],{},"re_*"," value. Sub-resources scoped under ",[58,3185,3186],{},"\u002Fcustomers\u002F{id}\u002F…"," (bank accounts, wallets, virtual accounts, blockchain wallets, offramp wallets) derive the parent from the URL, so no FK alias appears in the response body.",[12,3189,3190,3191,3193],{},"After the sunset, the ",[58,3192,108],{}," alias becomes the canonical field name across the API.",[16,3195,3197],{"id":3196},"webhook-changes","Webhook changes",[12,3199,3200],{},"Three new webhook events fire alongside the existing ones:",[21,3202,3203,3213,3221],{},[24,3204,3205,3208,3209,3212],{},[58,3206,3207],{},"customer.new",": fires whenever ",[58,3210,3211],{},"receiver.new"," fires",[24,3214,3215,3208,3218,3212],{},[58,3216,3217],{},"customer.update",[58,3219,3220],{},"receiver.update",[24,3222,3223,3208,3226,3212],{},[58,3224,3225],{},"customer.delete",[58,3227,3228],{},"receiver.delete",[12,3230,3231,3232,3239,3240,3243],{},"You ",[41,3233,3234,3235,3238],{},"must subscribe to ",[58,3236,3237],{},"customer.*"," before July 3, 2026",". After the sunset, ",[58,3241,3242],{},"receiver.*"," events stop firing entirely. If you don't migrate, your endpoint goes silent.",[12,3245,3246,3247,3249,3250,3252,3253,3255,3256,3258],{},"During the transition window (June 4 → July 3), every create and update emits both events: the legacy ",[58,3248,3242],{}," and its ",[58,3251,3237],{}," counterpart. If your endpoint is subscribed to both, your handler receives the same action twice. We intentionally dual-emit so you can migrate your handlers in any order, but make sure your processing is idempotent on the resource id, or drop the ",[58,3254,3242],{}," subscription once ",[58,3257,3237],{}," is wired up.",[16,3260,3262],{"id":3261},"sdk-updates","SDK updates",[2125,3264,3265,3278],{},[2128,3266,3267],{},[2131,3268,3269,3272,3275],{},[2134,3270,3271],{},"SDK",[2134,3273,3274],{},"Now (transition)",[2134,3276,3277],{},"At\u002Fafter sunset",[2147,3279,3280,3303,3320,3344,3362],{},[2131,3281,3282,3285,3298],{},[2152,3283,3284],{},"Node.js",[2152,3286,3287,3288,3290,3291,3293,3294,3297],{},"Minor release adds ",[58,3289,3060],{},", marks ",[58,3292,3064],{}," ",[58,3295,3296],{},"@deprecated"," in JSDoc.",[2152,3299,3300,3301,420],{},"Next major (4.0.0) removes ",[58,3302,3064],{},[2131,3304,3305,3308,3315],{},[2152,3306,3307],{},"Python",[2152,3309,3287,3310,3290,3312,3314],{},[58,3311,3060],{},[58,3313,3064],{}," deprecated with warning.",[2152,3316,3317,3318,420],{},"Next major (2.0.0) removes ",[58,3319,3064],{},[2131,3321,3322,3325,3336],{},[2152,3323,3324],{},"Go",[2152,3326,3287,3327,3329,3330,3333,3334,420],{},[58,3328,3060],{}," package, ",[58,3331,3332],{},"\u002F\u002F Deprecated:"," on ",[58,3335,3064],{},[2152,3337,3338,3293,3341,3343],{},[41,3339,3340],{},"No v2 planned for this rename.",[58,3342,3064],{}," stays as a deprecated forwarder in v1.",[2131,3345,3346,3349,3358],{},[2152,3347,3348],{},"PHP",[2152,3350,3287,3351,3290,3353,3293,3355,3357],{},[58,3352,3060],{},[58,3354,3064],{},[58,3356,3296],{}," in PHPDoc.",[2152,3359,3317,3360,420],{},[58,3361,3064],{},[2131,3363,3364,3367,3376],{},[2152,3365,3366],{},"Swift",[2152,3368,3287,3369,88,3371,3333,3374,420],{},[58,3370,3060],{},[58,3372,3373],{},"@available(*, deprecated)",[58,3375,3064],{},[2152,3377,3317,3378,420],{},[58,3379,3064],{},[12,3381,3382,3383,3385,3386,3388],{},"No import path changes during the transition. Just update to the latest version of your current major and the ",[58,3384,3060],{}," accessor is there. For Node, Python, PHP, and Swift, a future major release (after sunset) removes the deprecated ",[58,3387,3064],{}," surface; that's when imports change in those SDKs.",[12,3390,3391,3293,3394,3396,3397,88,3400,92,3403,3406],{},[41,3392,3393],{},"Go is treated differently.",[58,3395,3064],{}," stays as a thin deprecated forwarder in v1 indefinitely. ",[58,3398,3399],{},"gopls",[58,3401,3402],{},"staticcheck SA1019",[58,3404,3405],{},"godoc"," will flag usage; nothing breaks.",[12,3408,3409],{},"Method signatures are unchanged. Only the resource accessor renames. For most projects this is a single find\u002Freplace. Example in Node.js SDK:",[2594,3411,3415],{"className":3412,"code":3413,"language":3414,"meta":117,"style":117},"language-diff shiki shiki-themes github-light","- await blindpay.receivers.list()\n+ await blindpay.customers.list()\n\n- await blindpay.receivers.bankAccounts.create({ ... })\n+ await blindpay.customers.bankAccounts.create({ ... })\n","diff",[58,3416,3417,3422,3427,3432,3437],{"__ignoreMap":117},[3119,3418,3419],{"class":3121,"line":3122},[3119,3420,3421],{},"- await blindpay.receivers.list()\n",[3119,3423,3424],{"class":3121,"line":118},[3119,3425,3426],{},"+ await blindpay.customers.list()\n",[3119,3428,3429],{"class":3121,"line":1417},[3119,3430,3431],{"emptyLinePlaceholder":130},"\n",[3119,3433,3434],{"class":3121,"line":3156},[3119,3435,3436],{},"- await blindpay.receivers.bankAccounts.create({ ... })\n",[3119,3438,3439],{"class":3121,"line":3167},[3119,3440,3441],{},"+ await blindpay.customers.bankAccounts.create({ ... })\n",[16,3443,3445],{"id":3444},"what-you-need-to-do","What you need to do",[1181,3447,3448,3459,3471,3482],{},[24,3449,3450,3453,3454,3456,3457],{},[41,3451,3452],{},"Update your API calls"," to use ",[58,3455,3026],{}," instead of ",[58,3458,3022],{},[24,3460,3461,3464,3465,3467,3468,3470],{},[41,3462,3463],{},"Update field references"," from ",[58,3466,3176],{}," to ",[58,3469,108],{}," in your code",[24,3472,3473,3453,3476,88,3478,92,3480],{},[41,3474,3475],{},"Update webhook subscriptions",[58,3477,3207],{},[58,3479,3217],{},[58,3481,3225],{},[24,3483,3484,3487,3488,3490],{},[41,3485,3486],{},"Update your SDK"," to the latest version of its current major. The ",[58,3489,3060],{}," accessor is added there, no import changes required",[16,3492,3494],{"id":3493},"timeline","Timeline",[21,3496,3497,3521,3538],{},[24,3498,3499,3135,3502,3504,3505,80,3507,3509,3510,80,3513,3516,3517,3520],{},[41,3500,3501],{},"June 4, 2026",[58,3503,3026],{}," endpoints live. Both ",[58,3506,3022],{},[58,3508,3026],{}," accept requests. Receiver responses include ",[58,3511,3512],{},"Deprecation: true",[58,3514,3515],{},"Sunset: Fri, 03 Jul 2026 00:00:00 GMT"," headers, plus a ",[58,3518,3519],{},"Link: rel=\"successor-version\""," pointing to the customer equivalent.",[24,3522,3523,3525,3526,3044,3528,3530,3531,3533,3534,3537],{},[41,3524,3038],{},": Sunset date. ",[58,3527,3022],{},[58,3529,3047],{}," redirecting to ",[58,3532,3026],{},". SDK code calling ",[58,3535,3536],{},"receivers.*"," continues to work via the redirect.",[24,3539,3540,3135,3543,3545,3546,3548,3549,3551],{},[41,3541,3542],{},"Later",[58,3544,3022],{}," endpoints removed entirely. New SDK majors ship for Node (v4), Python (v2), PHP (v2), and Swift (v2), dropping the deprecated ",[58,3547,3064],{}," surface. The Go SDK keeps ",[58,3550,3064],{}," as a deprecated forwarder in v1; no v2 planned for this rename. Previous SDK majors enter maintenance mode (security fixes only).",[16,3553,3555],{"id":3554},"detect-deprecation-programmatically","Detect deprecation programmatically",[12,3557,3558,3559,3561],{},"Every ",[58,3560,3022],{}," response carries deprecation metadata you can monitor in tests or runtime logs:",[2594,3563,3567],{"className":3564,"code":3565,"language":3566,"meta":117,"style":117},"language-http shiki shiki-themes github-light","HTTP\u002F1.1 200 OK\nDeprecation: true\nSunset: Fri, 03 Jul 2026 00:00:00 GMT\nLink: \u003C\u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers>; rel=\"successor-version\"\nContent-Type: application\u002Fjson\n","http",[58,3568,3569,3574,3579,3584,3589],{"__ignoreMap":117},[3119,3570,3571],{"class":3121,"line":3122},[3119,3572,3573],{},"HTTP\u002F1.1 200 OK\n",[3119,3575,3576],{"class":3121,"line":118},[3119,3577,3578],{},"Deprecation: true\n",[3119,3580,3581],{"class":3121,"line":1417},[3119,3582,3583],{},"Sunset: Fri, 03 Jul 2026 00:00:00 GMT\n",[3119,3585,3586],{"class":3121,"line":3156},[3119,3587,3588],{},"Link: \u003C\u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers>; rel=\"successor-version\"\n",[3119,3590,3591],{"class":3121,"line":3167},[3119,3592,3593],{},"Content-Type: application\u002Fjson\n",[12,3595,3596,3597,3599],{},"Useful in CI: fail a smoke test if production traffic still hits ",[58,3598,3512],{}," endpoints close to the sunset date.",[16,3601,3603],{"id":3602},"verification-checklist","Verification checklist",[12,3605,3606],{},"Before considering your migration complete:",[21,3608,3609,3616,3622,3631,3637,3640],{},[24,3610,3611,3612,3615],{},"Logs show zero requests to ",[58,3613,3614],{},"\u002Fv1\u002Finstances\u002F*\u002Freceivers*"," paths from your services",[24,3617,3618,3619,3621],{},"CI \u002F monitoring asserts no ",[58,3620,3512],{}," header on production responses",[24,3623,3624,3625,88,3627,92,3629],{},"Webhook handlers process ",[58,3626,3207],{},[58,3628,3217],{},[58,3630,3225],{},[24,3632,3633,3634],{},"No code paths reference ",[58,3635,3636],{},"response.receiver_id",[24,3638,3639],{},"SDK updated to the latest minor release of its current major",[24,3641,3642,3643],{},"Saved dashboard URLs use ",[58,3644,3645],{},"\u002Fcustomers\u002F",[16,3647,3649],{"id":3648},"faq","FAQ",[1281,3651,3653],{"id":3652},"what-if-i-dont-migrate-before-july-3-2026","What if I don't migrate before July 3, 2026?",[12,3655,3656,3658,3659,3661,3662,3664,3665,88,3668,88,3671,3674],{},[58,3657,3022],{}," paths return ",[58,3660,3047],{}," pointing to the equivalent ",[58,3663,3026],{}," URL. Most HTTP clients (browsers, ",[58,3666,3667],{},"curl",[58,3669,3670],{},"requests",[58,3672,3673],{},"axios",", official SDKs, Postman) follow redirects automatically, so traffic keeps working, but you spend an extra round-trip per call and rely on redirect semantics. Migrate before that date.",[1281,3676,3678],{"id":3677},"can-i-migrate-one-resource-group-at-a-time","Can I migrate one resource group at a time?",[12,3680,3681],{},"Yes. The customer mirrors are independent per resource group (customers, bank accounts, wallets, virtual accounts, etc.). You can switch your customer-creation flow over this week and your bank-account-creation flow next week without coordination. Each endpoint accepts the new path independently.",[1281,3683,3685],{"id":3684},"will-i-get-duplicate-webhook-events-during-the-transition","Will I get duplicate webhook events during the transition?",[12,3687,3688,3689,80,3691,3693],{},"Yes, every create and update emits both ",[58,3690,3242],{},[58,3692,3237],{}," if you are subscribed to both. We dual-emit so you can migrate handlers in any order. Subscribe to one set or the other to avoid handling the same event twice.",[1281,3695,3697],{"id":3696},"do-i-need-to-migrate-my-stored-ids","Do I need to migrate my stored IDs?",[12,3699,3700,3701,3703,3704,80,3706,3708],{},"No. All IDs keep the ",[58,3702,3053],{}," prefix. The same ID works with both ",[58,3705,3022],{},[58,3707,3026],{}," endpoints. We are renaming the API surface, not the underlying resource.",[1281,3710,3712],{"id":3711},"how-do-i-report-issues-with-the-migration","How do I report issues with the migration?",[12,3714,3715,3716,3720,3721,3724,3725,3728],{},"Use the feedback button in the dashboard (under your profile dropdown) or email ",[46,3717,3719],{"href":3718},"mailto:support@blindpay.com","support@blindpay.com"," with ",[58,3722,3723],{},"migration"," in the subject. Including the request ID from a deprecated response (",[58,3726,3727],{},"x-blindpay-request-id"," header) speeds up the lookup.",[3730,3731,3732],"style",{},"html pre.shiki code .sgsFI, html code.shiki .sgsFI{--shiki-default:#24292E}html pre.shiki code .sYu0t, html code.shiki .sYu0t{--shiki-default:#005CC5}html pre.shiki code .sYBdl, html code.shiki .sYBdl{--shiki-default:#032F62}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}",{"title":117,"searchDepth":118,"depth":118,"links":3734},[3735,3736,3737,3738,3739,3740,3741,3742,3743,3744],{"id":18,"depth":118,"text":19},{"id":3068,"depth":118,"text":3069},{"id":3090,"depth":118,"text":3091},{"id":3196,"depth":118,"text":3197},{"id":3261,"depth":118,"text":3262},{"id":3444,"depth":118,"text":3445},{"id":3493,"depth":118,"text":3494},{"id":3554,"depth":118,"text":3555},{"id":3602,"depth":118,"text":3603},{"id":3648,"depth":118,"text":3649,"children":3745},[3746,3747,3748,3749,3750],{"id":3652,"depth":1417,"text":3653},{"id":3677,"depth":1417,"text":3678},{"id":3684,"depth":1417,"text":3685},{"id":3696,"depth":1417,"text":3697},{"id":3711,"depth":1417,"text":3712},"Migration","2026-06-04","We're renaming \"Receivers\" to \"Customers\" across the entire BlindPay platform. Both endpoints will work during a 1-month transition period.",{"excerpt":3755},{"type":9,"value":3756},[3757],[12,3758,3012],{},"\u002Fchangelog\u002F2026-06-04-customers-rename","---\ntitle: '\"Receivers\" renamed to \"Customers\"'\ndescription: We're renaming \"Receivers\" to \"Customers\" across the entire BlindPay platform. Both endpoints will work during a 1-month transition period.\ndate: 2026-06-04\ncategory: Migration\ncategoryType: update\nisChangelog: true\n---\n\nWe're renaming \"Receivers\" to \"Customers\" across the entire BlindPay platform: API endpoints, SDKs, documentation, and dashboard.\n\n\u003C!--more-->\n\n## TL;DR\n\n- All `\u002Freceivers` endpoints now have `\u002Fcustomers` equivalents\n- Both `\u002Freceivers` and `\u002Fcustomers` paths work identically through **July 3, 2026**\n- After that date, `\u002Freceivers` endpoints return `301 Moved Permanently`\n- IDs stay the same (`re_` prefix), no data migration needed\n- SDKs add a `customers` accessor to their current majors and `receivers` is deprecated alongside, no import changes required\n\n## What changed\n\nEvery API endpoint that previously used `\u002Freceivers` in its path now has a `\u002Fcustomers` equivalent:\n\n```\nGET    \u002Fv1\u002Finstances\u002F{instance_id}\u002Freceivers                →  GET    \u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers\nPOST   \u002Fv1\u002Finstances\u002F{instance_id}\u002Freceivers                →  POST   \u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers\nGET    \u002Fv1\u002Finstances\u002F{instance_id}\u002Freceivers\u002F{receiver_id}  →  GET    \u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers\u002F{customer_id}\nPUT    \u002Fv1\u002Finstances\u002F{instance_id}\u002Freceivers\u002F{receiver_id}  →  PUT    \u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers\u002F{customer_id}\nDELETE \u002Fv1\u002Finstances\u002F{instance_id}\u002Freceivers\u002F{receiver_id}  →  DELETE \u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers\u002F{customer_id}\n```\n\nThis applies to all sub-resources too: bank accounts, wallets, virtual accounts, blockchain wallets, offramp wallets, and limit increases.\n\n## Response changes\n\nDuring the transition period, every customer record returned by either `\u002Fcustomers` or `\u002Freceivers` carries a `customer_id` alias of its primary key. The underlying ID still uses the `re_` prefix and remains in the `id` field:\n\n```json\n{\n  \"id\": \"re_abc123456789\",\n  \"customer_id\": \"re_abc123456789\",\n  \"first_name\": \"Alice\"\n}\n```\n\nPayouts and payins that reference a customer expose both `receiver_id` and `customer_id` foreign-key fields during the transition; either accepts the same `re_*` value. Sub-resources scoped under `\u002Fcustomers\u002F{id}\u002F…` (bank accounts, wallets, virtual accounts, blockchain wallets, offramp wallets) derive the parent from the URL, so no FK alias appears in the response body.\n\nAfter the sunset, the `customer_id` alias becomes the canonical field name across the API.\n\n## Webhook changes\n\nThree new webhook events fire alongside the existing ones:\n\n- `customer.new`: fires whenever `receiver.new` fires\n- `customer.update`: fires whenever `receiver.update` fires\n- `customer.delete`: fires whenever `receiver.delete` fires\n\nYou **must subscribe to `customer.*` before July 3, 2026**. After the sunset, `receiver.*` events stop firing entirely. If you don't migrate, your endpoint goes silent.\n\nDuring the transition window (June 4 → July 3), every create and update emits both events: the legacy `receiver.*` and its `customer.*` counterpart. If your endpoint is subscribed to both, your handler receives the same action twice. We intentionally dual-emit so you can migrate your handlers in any order, but make sure your processing is idempotent on the resource id, or drop the `receiver.*` subscription once `customer.*` is wired up.\n\n## SDK updates\n\n| SDK     | Now (transition)                                                            | At\u002Fafter sunset                                                                       |\n| ------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |\n| Node.js | Minor release adds `customers`, marks `receivers` `@deprecated` in JSDoc.   | Next major (4.0.0) removes `receivers`.                                               |\n| Python  | Minor release adds `customers`, marks `receivers` deprecated with warning.  | Next major (2.0.0) removes `receivers`.                                               |\n| Go      | Minor release adds `customers` package, `\u002F\u002F Deprecated:` on `receivers`.    | **No v2 planned for this rename.** `receivers` stays as a deprecated forwarder in v1. |\n| PHP     | Minor release adds `customers`, marks `receivers` `@deprecated` in PHPDoc.  | Next major (2.0.0) removes `receivers`.                                               |\n| Swift   | Minor release adds `customers`, `@available(*, deprecated)` on `receivers`. | Next major (2.0.0) removes `receivers`.                                               |\n\nNo import path changes during the transition. Just update to the latest version of your current major and the `customers` accessor is there. For Node, Python, PHP, and Swift, a future major release (after sunset) removes the deprecated `receivers` surface; that's when imports change in those SDKs.\n\n**Go is treated differently.** `receivers` stays as a thin deprecated forwarder in v1 indefinitely. `gopls`, `staticcheck SA1019`, and `godoc` will flag usage; nothing breaks.\n\nMethod signatures are unchanged. Only the resource accessor renames. For most projects this is a single find\u002Freplace. Example in Node.js SDK:\n\n```diff\n- await blindpay.receivers.list()\n+ await blindpay.customers.list()\n\n- await blindpay.receivers.bankAccounts.create({ ... })\n+ await blindpay.customers.bankAccounts.create({ ... })\n```\n\n## What you need to do\n\n1. **Update your API calls** to use `\u002Fcustomers` instead of `\u002Freceivers`\n2. **Update field references** from `receiver_id` to `customer_id` in your code\n3. **Update webhook subscriptions** to use `customer.new`, `customer.update`, and `customer.delete`\n4. **Update your SDK** to the latest version of its current major. The `customers` accessor is added there, no import changes required\n\n## Timeline\n\n- **June 4, 2026**: `\u002Fcustomers` endpoints live. Both `\u002Freceivers` and `\u002Fcustomers` accept requests. Receiver responses include `Deprecation: true` and `Sunset: Fri, 03 Jul 2026 00:00:00 GMT` headers, plus a `Link: rel=\"successor-version\"` pointing to the customer equivalent.\n- **July 3, 2026**: Sunset date. `\u002Freceivers` endpoints return `301 Moved Permanently` redirecting to `\u002Fcustomers`. SDK code calling `receivers.*` continues to work via the redirect.\n- **Later**: `\u002Freceivers` endpoints removed entirely. New SDK majors ship for Node (v4), Python (v2), PHP (v2), and Swift (v2), dropping the deprecated `receivers` surface. The Go SDK keeps `receivers` as a deprecated forwarder in v1; no v2 planned for this rename. Previous SDK majors enter maintenance mode (security fixes only).\n\n## Detect deprecation programmatically\n\nEvery `\u002Freceivers` response carries deprecation metadata you can monitor in tests or runtime logs:\n\n```http\nHTTP\u002F1.1 200 OK\nDeprecation: true\nSunset: Fri, 03 Jul 2026 00:00:00 GMT\nLink: \u003C\u002Fv1\u002Finstances\u002F{instance_id}\u002Fcustomers>; rel=\"successor-version\"\nContent-Type: application\u002Fjson\n```\n\nUseful in CI: fail a smoke test if production traffic still hits `Deprecation: true` endpoints close to the sunset date.\n\n## Verification checklist\n\nBefore considering your migration complete:\n\n- Logs show zero requests to `\u002Fv1\u002Finstances\u002F*\u002Freceivers*` paths from your services\n- CI \u002F monitoring asserts no `Deprecation: true` header on production responses\n- Webhook handlers process `customer.new`, `customer.update`, and `customer.delete`\n- No code paths reference `response.receiver_id`\n- SDK updated to the latest minor release of its current major\n- Saved dashboard URLs use `\u002Fcustomers\u002F`\n\n## FAQ\n\n### What if I don't migrate before July 3, 2026?\n\n`\u002Freceivers` paths return `301 Moved Permanently` pointing to the equivalent `\u002Fcustomers` URL. Most HTTP clients (browsers, `curl`, `requests`, `axios`, official SDKs, Postman) follow redirects automatically, so traffic keeps working, but you spend an extra round-trip per call and rely on redirect semantics. Migrate before that date.\n\n### Can I migrate one resource group at a time?\n\nYes. The customer mirrors are independent per resource group (customers, bank accounts, wallets, virtual accounts, etc.). You can switch your customer-creation flow over this week and your bank-account-creation flow next week without coordination. Each endpoint accepts the new path independently.\n\n### Will I get duplicate webhook events during the transition?\n\nYes, every create and update emits both `receiver.*` and `customer.*` if you are subscribed to both. We dual-emit so you can migrate handlers in any order. Subscribe to one set or the other to avoid handling the same event twice.\n\n### Do I need to migrate my stored IDs?\n\nNo. All IDs keep the `re_` prefix. The same ID works with both `\u002Freceivers` and `\u002Fcustomers` endpoints. We are renaming the API surface, not the underlying resource.\n\n### How do I report issues with the migration?\n\nUse the feedback button in the dashboard (under your profile dropdown) or email support@blindpay.com with `migration` in the subject. Including the request ID from a deprecated response (`x-blindpay-request-id` header) speeds up the lookup.\n",{"title":3007,"description":3753},"changelog\u002F2026-06-04-customers-rename","HKBXALJT2NQ5CIm4XsSZpjBp7EWEW7Sf-SWnb-84Skw",{"id":3765,"title":3766,"author":7,"body":3767,"categories":7,"category":124,"categoryType":125,"date":3846,"description":3847,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":3848,"navigation":130,"path":3853,"rawbody":3854,"seo":3855,"stem":3856,"thumbnail":7,"__hash__":3857},"content\u002Fchangelog\u002F2026-06-06-sepa-multi-chain-eur-quotes-and-offramp.md","SEPA Multi-Chain, EUR-Amount Quotes, and Offramp Wallet Support",{"type":9,"value":3768,"toc":3839},[3769,3772,3774,3785,3789,3792,3795,3799,3802,3809,3823,3825,3828,3834,3836],[12,3770,3771],{},"Three updates to the SEPA EUR payouts rail we launched on May 29: more deposit chains, the ability to quote by the receiver's EUR amount, and offramp wallet support.",[16,3773,19],{"id":18},[21,3775,3776,3779,3782],{},[24,3777,3778],{},"USDC for SEPA is now accepted on Polygon, Ethereum, Arbitrum, Base, Solana, and Stellar",[24,3780,3781],{},"Quotes can be requested by the EUR amount the receiver should get, minimum 10 EUR. The existing USDC-amount mode is unchanged, minimum 11 USDC",[24,3783,3784],{},"SEPA bank accounts can be paired with offramp wallets on any of the supported deposit chains",[16,3786,3788],{"id":3787},"multi-chain-deposits","Multi-chain deposits",[12,3790,3791],{},"When you create a SEPA payout the USDC can come from any of these chains: Polygon, Ethereum, Arbitrum, Base, Solana, and Stellar. Settlement to the receiver's IBAN is unaffected, funds arrive within 5 to 30 minutes regardless of the source chain.",[12,3793,3794],{},"Native USDC only on each chain. Tron is not supported for SEPA.",[16,3796,3798],{"id":3797},"quote-by-eur-amount","Quote by EUR amount",[12,3800,3801],{},"Until now, every SEPA quote took a USDC amount and returned the EUR the receiver would get. You can now do the reverse: specify the EUR amount the receiver should receive and we calculate the USDC you need to send.",[12,3803,3804,3805,3808],{},"The mode is selected on the quote request via ",[58,3806,3807],{},"currency_type",":",[21,3810,3811,3817],{},[24,3812,3813,3816],{},[58,3814,3815],{},"currency_type: \"sender\""," for the USDC-amount path. Minimum 11 USDC.",[24,3818,3819,3822],{},[58,3820,3821],{},"currency_type: \"receiver\""," for the EUR-amount path. Minimum 10 EUR.",[16,3824,400],{"id":423},[12,3826,3827],{},"SEPA bank accounts can now be linked to offramp wallets on Polygon, Ethereum, Arbitrum, Base, and Solana. Funds sent to the offramp wallet are converted to EUR and settled to the linked IBAN automatically, with the same 5 to 30 minute window. Tron offramp wallets cannot be paired with SEPA bank accounts.",[12,3829,3830,3831,265],{},"See the ",[46,3832,3833],{"href":429},"offramp wallets documentation",[16,3835,2982],{"id":2981},[12,3837,3838],{},"These updates are live for every account that already has SEPA enabled. Existing SEPA bank accounts work with all the new chains and the EUR-amount quote mode without any reconfiguration.",{"title":117,"searchDepth":118,"depth":118,"links":3840},[3841,3842,3843,3844,3845],{"id":18,"depth":118,"text":19},{"id":3787,"depth":118,"text":3788},{"id":3797,"depth":118,"text":3798},{"id":423,"depth":118,"text":400},{"id":2981,"depth":118,"text":2982},"2026-06-06","SEPA payouts now accept USDC from Arbitrum, Base, Solana, and Stellar in addition to Polygon and Ethereum. Quotes can be requested by the EUR amount the receiver should get. SEPA bank accounts can also be linked to offramp wallets.",{"excerpt":3849},{"type":9,"value":3850},[3851],[12,3852,3771],{},"\u002Fchangelog\u002F2026-06-06-sepa-multi-chain-eur-quotes-and-offramp","---\ntitle: SEPA Multi-Chain, EUR-Amount Quotes, and Offramp Wallet Support\ndescription: SEPA payouts now accept USDC from Arbitrum, Base, Solana, and Stellar in addition to Polygon and Ethereum. Quotes can be requested by the EUR amount the receiver should get. SEPA bank accounts can also be linked to offramp wallets.\ndate: 2026-06-06\ncategory: Product Update\ncategoryType: update\nisChangelog: true\n---\n\nThree updates to the SEPA EUR payouts rail we launched on May 29: more deposit chains, the ability to quote by the receiver's EUR amount, and offramp wallet support.\n\n\u003C!--more-->\n\n## TL;DR\n\n- USDC for SEPA is now accepted on Polygon, Ethereum, Arbitrum, Base, Solana, and Stellar\n- Quotes can be requested by the EUR amount the receiver should get, minimum 10 EUR. The existing USDC-amount mode is unchanged, minimum 11 USDC\n- SEPA bank accounts can be paired with offramp wallets on any of the supported deposit chains\n\n## Multi-chain deposits\n\nWhen you create a SEPA payout the USDC can come from any of these chains: Polygon, Ethereum, Arbitrum, Base, Solana, and Stellar. Settlement to the receiver's IBAN is unaffected, funds arrive within 5 to 30 minutes regardless of the source chain.\n\nNative USDC only on each chain. Tron is not supported for SEPA.\n\n## Quote by EUR amount\n\nUntil now, every SEPA quote took a USDC amount and returned the EUR the receiver would get. You can now do the reverse: specify the EUR amount the receiver should receive and we calculate the USDC you need to send.\n\nThe mode is selected on the quote request via `currency_type`:\n\n- `currency_type: \"sender\"` for the USDC-amount path. Minimum 11 USDC.\n- `currency_type: \"receiver\"` for the EUR-amount path. Minimum 10 EUR.\n\n## Offramp wallets\n\nSEPA bank accounts can now be linked to offramp wallets on Polygon, Ethereum, Arbitrum, Base, and Solana. Funds sent to the offramp wallet are converted to EUR and settled to the linked IBAN automatically, with the same 5 to 30 minute window. Tron offramp wallets cannot be paired with SEPA bank accounts.\n\nSee the [offramp wallets documentation](\u002Fdocs\u002Fessentials\u002Fofframp-wallets) to get started.\n\n## Get started\n\nThese updates are live for every account that already has SEPA enabled. Existing SEPA bank accounts work with all the new chains and the EUR-amount quote mode without any reconfiguration.\n",{"title":3766,"description":3847},"changelog\u002F2026-06-06-sepa-multi-chain-eur-quotes-and-offramp","Yh8pOLqLz1Lu-v0Q5bDs81nL4MqLddN67Osbdf-S9oY",{"id":3859,"title":3860,"author":7,"body":3861,"categories":7,"category":2634,"categoryType":2635,"date":3978,"description":3979,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":3980,"navigation":130,"path":3987,"rawbody":3988,"seo":3989,"stem":3990,"thumbnail":7,"__hash__":3991},"content\u002Fchangelog\u002F2026-06-14-analyze-document.md","AI Document Analysis",{"type":9,"value":3862,"toc":3972},[3863,3870,3872,3909,3911,3922,3925,3929,3958,3960],[12,3864,3865,3866,3869],{},"You can now pre-screen KYC documents before submitting them. The new ",[58,3867,3868],{},"POST \u002Fv1\u002Fupload\u002Fanalyze"," endpoint reads a PDF, JPG, or PNG with AI, checks it against the rules for its type, and returns an approval-rate signal with a short reason.",[16,3871,19],{"id":18},[21,3873,3874,3879,3899,3902],{},[24,3875,3876,3877],{},"New endpoint: ",[58,3878,3868],{},[24,3880,3881,3882,3885,3886,88,3889,2519,3892,3895,3896],{},"Returns ",[58,3883,3884],{},"approval_rate"," of ",[58,3887,3888],{},"low",[58,3890,3891],{},"medium",[58,3893,3894],{},"high"," plus a one-line ",[58,3897,3898],{},"description",[24,3900,3901],{},"Supports 13 document types, from identity and passport to bank and financial statements",[24,3903,3904,3905,3908],{},"Optional ",[58,3906,3907],{},"metadata"," cross-checks values you already collected against the document",[16,3910,2878],{"id":2877},[12,3912,3913,3914,3917,3918,3921],{},"Send a ",[58,3915,3916],{},"file"," (PDF, JPG, or PNG up to 5MB) and a ",[58,3919,3920],{},"type",". The analysis runs the document against the rule set for that type and returns how confident it is that the document should be approved, with a short reason you can show to the customer or your reviewers.",[12,3923,3924],{},"The result is a signal, not a decision. KYC approval still comes from the verification flow; this lets you catch an expired ID or an out-of-date proof of address early, before submitting.",[16,3926,3928],{"id":3927},"optional-metadata","Optional metadata",[12,3930,3931,3932,3934,3935,88,3938,2519,3941,3944,3945,3947,3948,88,3951,88,3954,3957],{},"Pass ",[58,3933,3907],{}," as a JSON string of values you already have, such as ",[58,3936,3937],{},"full_name",[58,3939,3940],{},"date_of_birth",[58,3942,3943],{},"address",", and they are matched against the document. A clear mismatch caps the rating at ",[58,3946,3888],{}," and the reason explains it. Requested transaction limits (",[58,3949,3950],{},"requested_per_transaction",[58,3952,3953],{},"requested_daily",[58,3955,3956],{},"requested_monthly",") are checked for sufficient capacity instead of an exact match.",[16,3959,2982],{"id":2981},[12,3961,3830,3962,3966,3967,420],{},[46,3963,3965],{"href":3964},"\u002Fdocs\u002Fessentials\u002Fanalyze-document","Analyze Document documentation",". The full request and response schema is in the ",[46,3968,3971],{"href":3969,"rel":3970,"target":1153},"https:\u002F\u002Fapi.blindpay.com\u002Freference#tag\u002Fupload\u002FPOST\u002Fv1\u002Fupload\u002Fanalyze",[701],"BlindPay API Docs",{"title":117,"searchDepth":118,"depth":118,"links":3973},[3974,3975,3976,3977],{"id":18,"depth":118,"text":19},{"id":2877,"depth":118,"text":2878},{"id":3927,"depth":118,"text":3928},{"id":2981,"depth":118,"text":2982},"2026-06-14","A new endpoint reads a KYC document with AI and returns an approval-rate signal, so you can pre-screen files before submitting them for verification.",{"excerpt":3981},{"type":9,"value":3982},[3983],[12,3984,3865,3985,3869],{},[58,3986,3868],{},"\u002Fchangelog\u002F2026-06-14-analyze-document","---\ntitle: AI Document Analysis\ndescription: A new endpoint reads a KYC document with AI and returns an approval-rate signal, so you can pre-screen files before submitting them for verification.\ndate: 2026-06-14\ncategory: New Feature\ncategoryType: feature\nisChangelog: true\n---\n\nYou can now pre-screen KYC documents before submitting them. The new `POST \u002Fv1\u002Fupload\u002Fanalyze` endpoint reads a PDF, JPG, or PNG with AI, checks it against the rules for its type, and returns an approval-rate signal with a short reason.\n\n\u003C!--more-->\n\n## TL;DR\n\n- New endpoint: `POST \u002Fv1\u002Fupload\u002Fanalyze`\n- Returns `approval_rate` of `low`, `medium`, or `high` plus a one-line `description`\n- Supports 13 document types, from identity and passport to bank and financial statements\n- Optional `metadata` cross-checks values you already collected against the document\n\n## How it works\n\nSend a `file` (PDF, JPG, or PNG up to 5MB) and a `type`. The analysis runs the document against the rule set for that type and returns how confident it is that the document should be approved, with a short reason you can show to the customer or your reviewers.\n\nThe result is a signal, not a decision. KYC approval still comes from the verification flow; this lets you catch an expired ID or an out-of-date proof of address early, before submitting.\n\n## Optional metadata\n\nPass `metadata` as a JSON string of values you already have, such as `full_name`, `date_of_birth`, or `address`, and they are matched against the document. A clear mismatch caps the rating at `low` and the reason explains it. Requested transaction limits (`requested_per_transaction`, `requested_daily`, `requested_monthly`) are checked for sufficient capacity instead of an exact match.\n\n## Get started\n\nSee the [Analyze Document documentation](\u002Fdocs\u002Fessentials\u002Fanalyze-document). The full request and response schema is in the [BlindPay API Docs](https:\u002F\u002Fapi.blindpay.com\u002Freference#tag\u002Fupload\u002FPOST\u002Fv1\u002Fupload\u002Fanalyze){target=\"\\_blank\"}.\n",{"title":3860,"description":3979},"changelog\u002F2026-06-14-analyze-document","-Xzj6zfcW5w6rBtXFQ0_3wUWjMmvdlvBI9kDdG06BYE",{"id":3993,"title":3994,"author":7,"body":3995,"categories":7,"category":2634,"categoryType":2635,"date":4059,"description":4060,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":4061,"navigation":130,"path":4068,"rawbody":4069,"seo":4070,"stem":4071,"thumbnail":7,"__hash__":4072},"content\u002Fchangelog\u002F2026-07-03-instance-rfis.md","Instance RFIs",{"type":9,"value":3996,"toc":4055},[3997,4004,4006,4029,4031,4043],[12,3998,3999,4000,4003],{},"Requests for Information now come in two kinds. Alongside the existing customer RFIs, BlindPay compliance can open an RFI on your ",[41,4001,4002],{},"instance"," itself, for example to refresh business documents during a periodic review. Your team answers from the dashboard's instance settings page or through the API.",[16,4005,19],{"id":18},[21,4007,4008,4017,4020,4023,4026],{},[24,4009,4010,4011,80,4014],{},"New endpoints: ",[58,4012,4013],{},"GET \u002Fv1\u002Finstances\u002F{instance_id}\u002Frfi",[58,4015,4016],{},"POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Frfi",[24,4018,4019],{},"Same section and field format as customer RFIs",[24,4021,4022],{},"Standalone by design: no status changes, no blocked payments, ever",[24,4024,4025],{},"If the 27-day window passes, the request simply expires and compliance follows up directly",[24,4027,4028],{},"Email cadence to all instance members at day 0, 7, and 17, plus an expiry notice",[16,4030,2878],{"id":2877},[12,4032,4033,4034,4037,4038,4040,4041,420],{},"When compliance opens an instance RFI, every active member of your instance receives an email and the request appears under ",[41,4035,4036],{},"Settings → Instance"," in the dashboard. Fetch it with ",[58,4039,4013],{},", collect the requested fields, and submit them in a single shot with ",[58,4042,4016],{},[12,4044,4045,4046,2818,4050,4054],{},"Unlike customer RFIs, an instance RFI never touches your onboarding or KYB status and never blocks payins or payouts. See the ",[46,4047,4049],{"href":4048},"\u002Fdocs\u002Fessentials\u002Finstance-rfi","Instance RFI documentation",[46,4051,4053],{"href":4052},"\u002Fknowledge-base\u002Fguides\u002Finstance-requests","Instance RFIs guide"," for details.",{"title":117,"searchDepth":118,"depth":118,"links":4056},[4057,4058],{"id":18,"depth":118,"text":19},{"id":2877,"depth":118,"text":2878},"2026-07-03","Compliance can now request information about your instance itself, answered from the dashboard or via two new API endpoints, with no effect on your account status.",{"excerpt":4062},{"type":9,"value":4063},[4064],[12,4065,3999,4066,4003],{},[41,4067,4002],{},"\u002Fchangelog\u002F2026-07-03-instance-rfis","---\ntitle: Instance RFIs\ndescription: Compliance can now request information about your instance itself, answered from the dashboard or via two new API endpoints, with no effect on your account status.\ndate: 2026-07-03\ncategory: New Feature\ncategoryType: feature\nisChangelog: true\n---\n\nRequests for Information now come in two kinds. Alongside the existing customer RFIs, BlindPay compliance can open an RFI on your **instance** itself, for example to refresh business documents during a periodic review. Your team answers from the dashboard's instance settings page or through the API.\n\n\u003C!--more-->\n\n## TL;DR\n\n- New endpoints: `GET \u002Fv1\u002Finstances\u002F{instance_id}\u002Frfi` and `POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Frfi`\n- Same section and field format as customer RFIs\n- Standalone by design: no status changes, no blocked payments, ever\n- If the 27-day window passes, the request simply expires and compliance follows up directly\n- Email cadence to all instance members at day 0, 7, and 17, plus an expiry notice\n\n## How it works\n\nWhen compliance opens an instance RFI, every active member of your instance receives an email and the request appears under **Settings → Instance** in the dashboard. Fetch it with `GET \u002Fv1\u002Finstances\u002F{instance_id}\u002Frfi`, collect the requested fields, and submit them in a single shot with `POST \u002Fv1\u002Finstances\u002F{instance_id}\u002Frfi`.\n\nUnlike customer RFIs, an instance RFI never touches your onboarding or KYB status and never blocks payins or payouts. See the [Instance RFI documentation](\u002Fdocs\u002Fessentials\u002Finstance-rfi) and the [Instance RFIs guide](\u002Fknowledge-base\u002Fguides\u002Finstance-requests) for details.\n",{"title":3994,"description":4060},"changelog\u002F2026-07-03-instance-rfis","sjJzrqPRGkDR5ix3O5pdYtC6qeUhdLX4webqEnx0MUg",{"id":4074,"title":4075,"author":7,"body":4076,"categories":7,"category":124,"categoryType":125,"date":4188,"description":4189,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":4190,"navigation":130,"path":4195,"rawbody":4196,"seo":4197,"stem":4198,"thumbnail":7,"__hash__":4199},"content\u002Fchangelog\u002F2026-07-20-error-codes-new-docs-ai-assistant.md","Public Error Codes, New Documentation, and AI in the Docs",{"type":9,"value":4077,"toc":4181},[4078,4081,4083,4118,4122,4134,4140,4144,4151,4158,4162,4165,4168,4171,4175],[12,4079,4080],{},"July's product updates: API errors become predictable and safe to show your users, the documentation gets a full rebuild, and you can now ask the docs anything.",[16,4082,19],{"id":18},[21,4084,4085,4096,4102,4108],{},[24,4086,4087,4090,4091,4093,4094],{},[41,4088,4089],{},"Public error codes:"," every API error now returns a stable ",[58,4092,58],{}," and a safe-to-display ",[58,4095,3898],{},[24,4097,4098,4101],{},[41,4099,4100],{},"New documentation:"," rebuilt navigation, REST-only quickstarts, and a self-hosted API reference",[24,4103,4104,4107],{},[41,4105,4106],{},"AI in the docs:"," an assistant that knows our entire API and answers instantly",[24,4109,4110,4113,4114,4117],{},[41,4111,4112],{},"Idempotency keys:"," opt-in ",[58,4115,4116],{},"Idempotency-Key"," header on all mutating v1 endpoints",[16,4119,4121],{"id":4120},"public-error-codes","Public error codes",[12,4123,4124,4125,4127,4128,92,4131,4133],{},"Every API error response now includes two additive fields: ",[58,4126,58],{},", a stable identifier like ",[58,4129,4130],{},"PAYOUTS_INSUFFICIENT_BALANCE",[58,4132,3898],{},", human-readable text safe to show your end users. Existing responses are unchanged, so nothing breaks.",[12,4135,4136,4137,420],{},"Each code is documented with its retry semantics, so your integration knows whether to retry, stop, or ask the user to act. Browse the full list in the ",[46,4138,104],{"href":4139,"target":1153},"\u002Fdocs\u002Fapi\u002Freference",[16,4141,4143],{"id":4142},"new-documentation","New documentation",[12,4145,4146,4147,4150],{},"We rebuilt ",[46,4148,4149],{"href":2024},"blindpay.com\u002Fdocs"," from the ground up. Navigation is organized around what you are doing (Payins, Payouts, Send, Receive, Store), and every quickstart is REST-only with managed wallets, so you can integrate without touching blockchain tooling.",[12,4152,4153,4154,4157],{},"The API reference now lives at ",[46,4155,4156],{"href":4139,"target":1153},"blindpay.com\u002Fdocs\u002Fapi\u002Freference"," with one URL per endpoint. All old URLs redirect.",[16,4159,4161],{"id":4160},"ai-in-the-docs","AI in the docs",[12,4163,4164],{},"The docs now answer back. An AI assistant trained on our entire documentation and API reference is built into every page: ask \"how do I create a payout quote\" or paste an error code, and it gives you a direct answer with working request examples, no page hunting.",[12,4166,4167],{},"It is the fastest way to integrate BlindPay. Most questions that used to become support tickets now get answered in seconds, right where you are working.",[12,4169,4170],{},"And this is just the start: the same AI is coming to the dashboard next, where you will be able to run your entire operation by simply asking in plain language.",[16,4172,4174],{"id":4173},"idempotency-keys","Idempotency keys",[12,4176,4177,4178,4180],{},"Mutating v1 endpoints now accept an optional ",[58,4179,4116],{}," header. Retry with the same key and you get the original response back instead of a duplicate action, making timeouts and retries safe on payment-creating calls.",{"title":117,"searchDepth":118,"depth":118,"links":4182},[4183,4184,4185,4186,4187],{"id":18,"depth":118,"text":19},{"id":4120,"depth":118,"text":4121},{"id":4142,"depth":118,"text":4143},{"id":4160,"depth":118,"text":4161},{"id":4173,"depth":118,"text":4174},"2026-07-20","Stable error codes with safe-to-display descriptions on every API error, a rebuilt documentation site with an AI assistant built in, and opt-in request idempotency.",{"excerpt":4191},{"type":9,"value":4192},[4193],[12,4194,4080],{},"\u002Fchangelog\u002F2026-07-20-error-codes-new-docs-ai-assistant","---\ntitle: Public Error Codes, New Documentation, and AI in the Docs\ndescription: Stable error codes with safe-to-display descriptions on every API error, a rebuilt documentation site with an AI assistant built in, and opt-in request idempotency.\ndate: 2026-07-20\ncategory: Product Update\ncategoryType: update\nisChangelog: true\n---\n\nJuly's product updates: API errors become predictable and safe to show your users, the documentation gets a full rebuild, and you can now ask the docs anything.\n\n\u003C!--more-->\n\n## TL;DR\n\n- **Public error codes:** every API error now returns a stable `code` and a safe-to-display `description`\n- **New documentation:** rebuilt navigation, REST-only quickstarts, and a self-hosted API reference\n- **AI in the docs:** an assistant that knows our entire API and answers instantly\n- **Idempotency keys:** opt-in `Idempotency-Key` header on all mutating v1 endpoints\n\n## Public error codes\n\nEvery API error response now includes two additive fields: `code`, a stable identifier like `PAYOUTS_INSUFFICIENT_BALANCE`, and `description`, human-readable text safe to show your end users. Existing responses are unchanged, so nothing breaks.\n\nEach code is documented with its retry semantics, so your integration knows whether to retry, stop, or ask the user to act. Browse the full list in the [API reference](\u002Fdocs\u002Fapi\u002Freference){target=\"\\_blank\"}.\n\n## New documentation\n\nWe rebuilt [blindpay.com\u002Fdocs](\u002Fdocs) from the ground up. Navigation is organized around what you are doing (Payins, Payouts, Send, Receive, Store), and every quickstart is REST-only with managed wallets, so you can integrate without touching blockchain tooling.\n\nThe API reference now lives at [blindpay.com\u002Fdocs\u002Fapi\u002Freference](\u002Fdocs\u002Fapi\u002Freference){target=\"\\_blank\"} with one URL per endpoint. All old URLs redirect.\n\n## AI in the docs\n\nThe docs now answer back. An AI assistant trained on our entire documentation and API reference is built into every page: ask \"how do I create a payout quote\" or paste an error code, and it gives you a direct answer with working request examples, no page hunting.\n\nIt is the fastest way to integrate BlindPay. Most questions that used to become support tickets now get answered in seconds, right where you are working.\n\nAnd this is just the start: the same AI is coming to the dashboard next, where you will be able to run your entire operation by simply asking in plain language.\n\n## Idempotency keys\n\nMutating v1 endpoints now accept an optional `Idempotency-Key` header. Retry with the same key and you get the original response back instead of a duplicate action, making timeouts and retries safe on payment-creating calls.\n",{"title":4075,"description":4189},"changelog\u002F2026-07-20-error-codes-new-docs-ai-assistant","0E7m8DWeBohqDcsKdPKt5gj8ffnVyYYJJq18TlEYoqs",{"id":4201,"title":4202,"author":7,"body":4203,"categories":7,"category":3751,"categoryType":125,"date":5288,"description":5289,"extension":128,"faq":7,"howto":7,"isBlog":129,"isChangelog":130,"meta":5290,"navigation":130,"path":5305,"rawbody":5306,"seo":5307,"stem":5308,"thumbnail":7,"__hash__":5309},"content\u002Fchangelog\u002F2026-07-27-customers-rename-sunset.md","\"Receivers\" to \"Customers\" migration: final notice and complete guide",{"type":9,"value":4204,"toc":5266},[4205,4212,4226,4230,4242,4304,4311,4322,4326,4342,4346,4551,4555,4567,4580,4590,4594,4599,4743,4747,4760,4952,4974,4978,4995,4999,5011,5015,5018,5024,5026,5087,5095,5097,5170,5172,5176,5209,5211,5221,5228,5239,5243,5255,5257],[12,4206,4207,4208,4211],{},"The transition period announced in the ",[46,4209,4210],{"href":3759},"June 4 changelog"," has ended, and the final release that makes \"customers\" the only name across the BlindPay platform is about to roll out. This post is the complete guide to everything that changes.",[12,4213,4214,4217,4218,4221,4222,4225],{},[41,4215,4216],{},"Timing: the renames below are not live yet."," They ship with the final release, which will be announced on this changelog. Until then, the ",[58,4219,4220],{},"receiver_*"," request fields remain the accepted shape on the current API (sending ",[58,4223,4224],{},"customer_*"," request fields today is rejected). Use this guide, and the AI prompt at the end, to prepare your migration diff now, and deploy it when the release goes live.",[16,4227,4229],{"id":4228},"endpoints","Endpoints",[12,4231,4232,4233,4235,4236,4238,4239,4241],{},"Every legacy ",[58,4234,3022],{}," path now returns ",[58,4237,3047],{}," pointing at its ",[58,4240,3026],{}," equivalent.",[2125,4243,4244,4254],{},[2128,4245,4246],{},[2131,4247,4248,4251],{},[2134,4249,4250],{},"Was",[2134,4252,4253],{},"Now",[2147,4255,4256,4268,4280,4292],{},[2131,4257,4258,4263],{},[2152,4259,4260],{},[58,4261,4262],{},"\u002Fv1\u002Finstances\u002F{id}\u002Freceivers[\u002F...]",[2152,4264,4265],{},[58,4266,4267],{},"\u002Fv1\u002Finstances\u002F{id}\u002Fcustomers[\u002F...]",[2131,4269,4270,4275],{},[2152,4271,4272],{},[58,4273,4274],{},"\u002Fv1\u002Fe\u002Finstances\u002F{id}\u002Freceivers[\u002F...]",[2152,4276,4277],{},[58,4278,4279],{},"\u002Fv1\u002Fe\u002Finstances\u002F{id}\u002Fcustomers[\u002F...]",[2131,4281,4282,4287],{},[2152,4283,4284],{},[58,4285,4286],{},"\u002Fv1\u002Finstances\u002F{id}\u002Flimits\u002Freceivers\u002F{id}",[2152,4288,4289],{},[58,4290,4291],{},"\u002Fv1\u002Finstances\u002F{id}\u002Flimits\u002Fcustomers\u002F{id}",[2131,4293,4294,4299],{},[2152,4295,4296],{},[58,4297,4298],{},"\u002Fv1\u002Finstances\u002F{id}\u002Fexternal-receiver-token",[2152,4300,4301],{},[58,4302,4303],{},"\u002Fv1\u002Finstances\u002F{id}\u002Fexternal-customer-token",[12,4305,4306,4307,4310],{},"This covers the customer collection and item routes plus every sub-resource: bank accounts, wallets, blockchain wallets, virtual accounts, offramp wallets, limits, limit increases, and RFIs. The ",[58,4308,4309],{},"\u002Fe\u002F"," external invite-flow variants redirect too.",[12,4312,4313,4314,4317,4318,4321],{},"Note that ",[58,4315,4316],{},"external-receiver-token"," is renamed even though it has no ",[58,4319,4320],{},"\u002Freceivers\u002F"," path segment.",[16,4323,4325],{"id":4324},"webhooks","Webhooks",[12,4327,4328,88,4330,92,4332,4334,4335,88,4337,92,4339,4341],{},[58,4329,3211],{},[58,4331,3220],{},[58,4333,3228],{}," no longer fire. Subscribe to ",[58,4336,3207],{},[58,4338,3217],{},[58,4340,3225],{}," instead; they carry the same payloads. The dual-emit behavior from the transition window is gone, so you now receive exactly one event per action.",[16,4343,4345],{"id":4344},"renamed-fields","Renamed fields",[2125,4347,4348,4359],{},[2128,4349,4350],{},[2131,4351,4352,4354,4356],{},[2134,4353,4250],{},[2134,4355,4253],{},[2134,4357,4358],{},"Where",[2147,4360,4361,4374,4389,4404,4419,4433,4447,4462,4476,4494,4509,4523,4537],{},[2131,4362,4363,4367,4371],{},[2152,4364,4365],{},[58,4366,3176],{},[2152,4368,4369],{},[58,4370,108],{},[2152,4372,4373],{},"Payins, payouts, quotes, transfers, bank accounts, wallets, blockchain wallets, virtual accounts, offramp wallets, limit increases, RFIs, TOS. Also the path segment and list filter.",[2131,4375,4376,4381,4386],{},[2152,4377,4378],{},[58,4379,4380],{},"receiver_name",[2152,4382,4383],{},[58,4384,4385],{},"customer_name",[2152,4387,4388],{},"Customer list filter query parameter",[2131,4390,4391,4396,4401],{},[2152,4392,4393],{},[58,4394,4395],{},"receiver_local_amount",[2152,4397,4398],{},[58,4399,4400],{},"customer_local_amount",[2152,4402,4403],{},"Quotes, payouts",[2131,4405,4406,4411,4416],{},[2152,4407,4408],{},[58,4409,4410],{},"receiver_wallet_address",[2152,4412,4413],{},[58,4414,4415],{},"customer_wallet_address",[2152,4417,4418],{},"Transfers, transfer quotes",[2131,4420,4421,4426,4431],{},[2152,4422,4423],{},[58,4424,4425],{},"receiver_network",[2152,4427,4428],{},[58,4429,4430],{},"customer_network",[2152,4432,4418],{},[2131,4434,4435,4440,4445],{},[2152,4436,4437],{},[58,4438,4439],{},"receiver_token",[2152,4441,4442],{},[58,4443,4444],{},"customer_token",[2152,4446,4418],{},[2131,4448,4449,4454,4459],{},[2152,4450,4451],{},[58,4452,4453],{},"receiver_invite_redirect_url",[2152,4455,4456],{},[58,4457,4458],{},"customer_invite_redirect_url",[2152,4460,4461],{},"Instance settings",[2131,4463,4464,4469,4474],{},[2152,4465,4466],{},[58,4467,4468],{},"receiver_rfi_emails_enabled",[2152,4470,4471],{},[58,4472,4473],{},"customer_rfi_emails_enabled",[2152,4475,4461],{},[2131,4477,4478,4483,4488],{},[2152,4479,4480],{},[58,4481,4482],{},"receivers_amount",[2152,4484,4485],{},[58,4486,4487],{},"customers_amount",[2152,4489,4490,4493],{},[58,4491,4492],{},"GET \u002Fv1\u002Finstances",", the count of customers on the instance",[2131,4495,4496,4501,4506],{},[2152,4497,4498],{},[58,4499,4500],{},"receiver_type",[2152,4502,4503],{},[58,4504,4505],{},"customer_type",[2152,4507,4508],{},"RFI",[2131,4510,4511,4516,4521],{},[2152,4512,4513],{},[58,4514,4515],{},"receiver_kyc_status",[2152,4517,4518],{},[58,4519,4520],{},"customer_kyc_status",[2152,4522,4508],{},[2131,4524,4525,4530,4535],{},[2152,4526,4527],{},[58,4528,4529],{},"receiver_aiprise_session_id",[2152,4531,4532],{},[58,4533,4534],{},"customer_aiprise_session_id",[2152,4536,4508],{},[2131,4538,4539,4544,4549],{},[2152,4540,4541],{},[58,4542,4543],{},"receiver_aiprise_user_profile_id",[2152,4545,4546],{},[58,4547,4548],{},"customer_aiprise_user_profile_id",[2152,4550,4508],{},[1281,4552,4554],{"id":4553},"the-one-field-that-keeps-its-name","The one field that keeps its name",[12,4556,4557,1382,4560,4563,4564,4566],{},[58,4558,4559],{},"receiver_amount",[41,4561,4562],{},"not"," renamed. It stays ",[58,4565,4559],{}," on quotes, payins, payouts, and transfers, because there it means \"the amount the receiving side gets\", a leg of the transaction rather than a reference to the customer resource.",[12,4568,4569,4570,4572,4573,4576,4577,4579],{},"Do not confuse it with ",[58,4571,4482],{}," (plural), which ",[41,4574,4575],{},"is"," renamed to ",[58,4578,4487],{},". That one is the customer count on an instance.",[12,4581,4582,4583,3467,4586,4589],{},"This is the single reason a blind find-and-replace of ",[58,4584,4585],{},"receiver",[58,4587,4588],{},"customer"," will break your integration.",[16,4591,4593],{"id":4592},"renamed-error-codes","Renamed error codes",[12,4595,76,4596,4598],{},[58,4597,58],{}," field on error responses is a stable identifier meant for programmatic handling, and eleven of them changed prefix.",[2125,4600,4601,4609],{},[2128,4602,4603],{},[2131,4604,4605,4607],{},[2134,4606,4250],{},[2134,4608,4253],{},[2147,4610,4611,4623,4635,4647,4659,4671,4683,4695,4707,4719,4731],{},[2131,4612,4613,4618],{},[2152,4614,4615],{},[58,4616,4617],{},"RECEIVERS_NOT_FOUND",[2152,4619,4620],{},[58,4621,4622],{},"CUSTOMERS_NOT_FOUND",[2131,4624,4625,4630],{},[2152,4626,4627],{},[58,4628,4629],{},"RECEIVERS_ALREADY_APPROVED",[2152,4631,4632],{},[58,4633,4634],{},"CUSTOMERS_ALREADY_APPROVED",[2131,4636,4637,4642],{},[2152,4638,4639],{},[58,4640,4641],{},"RECEIVERS_KYC_NOT_APPROVED",[2152,4643,4644],{},[58,4645,4646],{},"CUSTOMERS_KYC_NOT_APPROVED",[2131,4648,4649,4654],{},[2152,4650,4651],{},[58,4652,4653],{},"RECEIVERS_ONBOARDING_INCOMPLETE",[2152,4655,4656],{},[58,4657,4658],{},"CUSTOMERS_ONBOARDING_INCOMPLETE",[2131,4660,4661,4666],{},[2152,4662,4663],{},[58,4664,4665],{},"RECEIVERS_INVALID_DATA",[2152,4667,4668],{},[58,4669,4670],{},"CUSTOMERS_INVALID_DATA",[2131,4672,4673,4678],{},[2152,4674,4675],{},[58,4676,4677],{},"RECEIVERS_INVALID_PHONE",[2152,4679,4680],{},[58,4681,4682],{},"CUSTOMERS_INVALID_PHONE",[2131,4684,4685,4690],{},[2152,4686,4687],{},[58,4688,4689],{},"RECEIVERS_INVALID_TAX_ID",[2152,4691,4692],{},[58,4693,4694],{},"CUSTOMERS_INVALID_TAX_ID",[2131,4696,4697,4702],{},[2152,4698,4699],{},[58,4700,4701],{},"RECEIVERS_ID_DOCUMENT_INVALID",[2152,4703,4704],{},[58,4705,4706],{},"CUSTOMERS_ID_DOCUMENT_INVALID",[2131,4708,4709,4714],{},[2152,4710,4711],{},[58,4712,4713],{},"RECEIVERS_COUNTRY_NOT_SUPPORTED",[2152,4715,4716],{},[58,4717,4718],{},"CUSTOMERS_COUNTRY_NOT_SUPPORTED",[2131,4720,4721,4726],{},[2152,4722,4723],{},[58,4724,4725],{},"RECEIVERS_ENHANCED_KYC_REQUIRED",[2152,4727,4728],{},[58,4729,4730],{},"CUSTOMERS_ENHANCED_KYC_REQUIRED",[2131,4732,4733,4738],{},[2152,4734,4735],{},[58,4736,4737],{},"RECEIVERS_BUSINESS_ENHANCED_NOT_AVAILABLE",[2152,4739,4740],{},[58,4741,4742],{},"CUSTOMERS_BUSINESS_ENHANCED_NOT_AVAILABLE",[16,4744,4746],{"id":4745},"renamed-error-messages","Renamed error messages",[12,4748,4749,4750,4753,4754,4756,4757,4759],{},"The legacy ",[58,4751,4752],{},"message"," slug also changed on the errors below. If you branch on ",[58,4755,4752],{}," rather than ",[58,4758,58],{},", update both.",[2125,4761,4762,4770],{},[2128,4763,4764],{},[2131,4765,4766,4768],{},[2134,4767,4250],{},[2134,4769,4253],{},[2147,4771,4772,4784,4796,4808,4820,4832,4844,4856,4868,4880,4892,4904,4916,4928,4940],{},[2131,4773,4774,4779],{},[2152,4775,4776],{},[58,4777,4778],{},"receiver_not_found",[2152,4780,4781],{},[58,4782,4783],{},"customer_not_found",[2131,4785,4786,4791],{},[2152,4787,4788],{},[58,4789,4790],{},"receiver_id_not_found",[2152,4792,4793],{},[58,4794,4795],{},"customer_id_not_found",[2131,4797,4798,4803],{},[2152,4799,4800],{},[58,4801,4802],{},"receiver_already_approved",[2152,4804,4805],{},[58,4806,4807],{},"customer_already_approved",[2131,4809,4810,4815],{},[2152,4811,4812],{},[58,4813,4814],{},"receiver_kyc_not_approved",[2152,4816,4817],{},[58,4818,4819],{},"customer_kyc_not_approved",[2131,4821,4822,4827],{},[2152,4823,4824],{},[58,4825,4826],{},"receiver_not_approved",[2152,4828,4829],{},[58,4830,4831],{},"customer_not_approved",[2131,4833,4834,4839],{},[2152,4835,4836],{},[58,4837,4838],{},"receiver_limit_not_found",[2152,4840,4841],{},[58,4842,4843],{},"customer_limit_not_found",[2131,4845,4846,4851],{},[2152,4847,4848],{},[58,4849,4850],{},"receiver_already_has_limit_increase_in_review",[2152,4852,4853],{},[58,4854,4855],{},"customer_already_has_limit_increase_in_review",[2131,4857,4858,4863],{},[2152,4859,4860],{},[58,4861,4862],{},"vm_invalid_receiver_data",[2152,4864,4865],{},[58,4866,4867],{},"vm_invalid_customer_data",[2131,4869,4870,4875],{},[2152,4871,4872],{},[58,4873,4874],{},"vm_receiver_country_not_supported",[2152,4876,4877],{},[58,4878,4879],{},"vm_customer_country_not_supported",[2131,4881,4882,4887],{},[2152,4883,4884],{},[58,4885,4886],{},"vm_unsupported_receiver_type",[2152,4888,4889],{},[58,4890,4891],{},"vm_unsupported_customer_type",[2131,4893,4894,4899],{},[2152,4895,4896],{},[58,4897,4898],{},"zenus_business_va_requires_business_receiver",[2152,4900,4901],{},[58,4902,4903],{},"zenus_business_va_requires_business_customer",[2131,4905,4906,4911],{},[2152,4907,4908],{},[58,4909,4910],{},"beneficiary_name_must_match_receiver_for_first_party",[2152,4912,4913],{},[58,4914,4915],{},"beneficiary_name_must_match_customer_for_first_party",[2131,4917,4918,4923],{},[2152,4919,4920],{},[58,4921,4922],{},"blockchain_wallet_does_not_belong_to_receiver",[2152,4924,4925],{},[58,4926,4927],{},"blockchain_wallet_does_not_belong_to_customer",[2131,4929,4930,4935],{},[2152,4931,4932],{},[58,4933,4934],{},"sender_and_receiver_networks_must_be_the_same",[2152,4936,4937],{},[58,4938,4939],{},"sender_and_customer_networks_must_be_the_same",[2131,4941,4942,4947],{},[2152,4943,4944],{},[58,4945,4946],{},"sender_and_receiver_tokens_must_be_the_same",[2152,4948,4949],{},[58,4950,4951],{},"sender_and_customer_tokens_must_be_the_same",[12,4953,4954,4955,4957,4958,4961,4962,4964,4965,4967,4968,80,4971,4973],{},"Two ",[58,4956,4752],{}," slugs are deliberately unchanged, because they describe the receiving leg of a transaction rather than the customer resource: ",[58,4959,4960],{},"otc_only_supported_for_sender_without_cover_fees_and_receiver_with_cover_fees",", and every slug involving ",[58,4963,4559],{},". The ",[58,4966,3807],{}," request enum also keeps its ",[58,4969,4970],{},"sender",[58,4972,4585],{}," values.",[16,4975,4977],{"id":4976},"deprecation-headers-are-gone","Deprecation headers are gone",[12,4979,4980,4982,4983,88,4985,2519,4988,4990,4991,4994],{},[58,4981,3022],{}," responses no longer carry ",[58,4984,3512],{},[58,4986,4987],{},"Sunset",[58,4989,3519],{},". If you set up the CI smoke test suggested in the June changelog, it now passes trivially instead of catching anything. Replace it with a check that asserts no ",[58,4992,4993],{},"301"," responses from BlindPay.",[16,4996,4998],{"id":4997},"ids-are-unchanged","IDs are unchanged",[12,5000,5001,5002,5004,5005,5007,5008,5010],{},"Customer IDs keep the ",[58,5003,3053],{}," prefix, and customer records keep both ",[58,5006,3109],{}," and its canonical alias ",[58,5009,108],{},". No data migration is needed. Do not rewrite stored IDs.",[16,5012,5014],{"id":5013},"migrate-your-code-with-an-ai-agent","Migrate your code with an AI agent",[12,5016,5017],{},"If you use an AI coding agent (Claude Code, Codex, Cursor, Windsurf, or similar), paste the prompt below into it from the root of your integration. It contains every rename from this changelog and the June announcement, including the exceptions that make a naive find-and-replace unsafe.",[2594,5019,5022],{"className":5020,"code":5021,"language":2599,"meta":117},[2597],"Migrate this codebase off the deprecated BlindPay \"receivers\" API surface and onto\n\"customers\". This is a rename of the API surface only: resource IDs are unchanged.\n\nWork through the steps in order and show me a diff before applying anything.\n\nSTEP 1 - Find every call site.\nSearch the whole repo (including tests, fixtures, recorded HTTP cassettes, env\nfiles, OpenAPI\u002FPostman collections, infrastructure config, and docs) for:\n  receivers, receiver_, receiverId, RECEIVERS_, \"receiver.\" (webhook event names)\n\nSTEP 2 - Rewrite URL paths.\n  \u002Fv1\u002Finstances\u002F{id}\u002Freceivers               -> \u002Fv1\u002Finstances\u002F{id}\u002Fcustomers\n  \u002Fv1\u002Fe\u002Finstances\u002F{id}\u002Freceivers             -> \u002Fv1\u002Fe\u002Finstances\u002F{id}\u002Fcustomers\n  \u002Fv1\u002Finstances\u002F{id}\u002Flimits\u002Freceivers\u002F{rid}  -> \u002Fv1\u002Finstances\u002F{id}\u002Flimits\u002Fcustomers\u002F{rid}\n  \u002Fv1\u002Finstances\u002F{id}\u002Fexternal-receiver-token -> \u002Fv1\u002Finstances\u002F{id}\u002Fexternal-customer-token\nApply to all sub-resources as well: bank-accounts, wallets, blockchain-wallets,\nvirtual-accounts, offramp-wallets, limit-increase, rfi.\nThe old paths still answer 301, so nothing breaks immediately, but every call\ncosts an extra round-trip until this is done.\n\nSTEP 3 - Rename request and response fields.\n  receiver_id                      -> customer_id\n  receiver_name                    -> customer_name\n  receiver_local_amount            -> customer_local_amount\n  receiver_wallet_address          -> customer_wallet_address\n  receiver_network                 -> customer_network\n  receiver_token                   -> customer_token\n  receiver_invite_redirect_url     -> customer_invite_redirect_url\n  receiver_rfi_emails_enabled      -> customer_rfi_emails_enabled\n  receivers_amount                 -> customers_amount\n  receiver_type                    -> customer_type\n  receiver_kyc_status              -> customer_kyc_status\n  receiver_aiprise_session_id      -> customer_aiprise_session_id\n  receiver_aiprise_user_profile_id -> customer_aiprise_user_profile_id\n\nSTEP 4 - CRITICAL EXCEPTION. Do NOT rename receiver_amount.\nreceiver_amount (singular) is still called receiver_amount on quotes, payins,\npayouts, and transfers. It means \"amount the receiving side gets\", not a\nreference to the customer resource. Renaming it will break those calls.\nNote the near-miss: receivers_amount (plural, the customer count on\nGET \u002Fv1\u002Finstances) IS renamed to customers_amount. Handle each explicitly.\nNever run a blanket s\u002Freceiver\u002Fcustomer\u002F over this repo.\n\nSTEP 5 - Rename webhook event names and handlers.\n  receiver.new    -> customer.new\n  receiver.update -> customer.update\n  receiver.delete -> customer.delete\nPayloads are identical. Also update the subscription list in the BlindPay\ndashboard; a code-only change will leave your endpoint silent.\nThe old dual-emit is gone, so if a handler was de-duplicating receiver.* against\ncustomer.* for the same action, that workaround can be removed.\n\nSTEP 6 - Rename error codes checked in code.\nAny comparison against the code field on an error response:\n  RECEIVERS_NOT_FOUND -> CUSTOMERS_NOT_FOUND, and the same CUSTOMERS_ prefix\n  swap for ALREADY_APPROVED, KYC_NOT_APPROVED, ONBOARDING_INCOMPLETE,\n  INVALID_DATA, INVALID_PHONE, INVALID_TAX_ID, ID_DOCUMENT_INVALID,\n  COUNTRY_NOT_SUPPORTED, ENHANCED_KYC_REQUIRED,\n  BUSINESS_ENHANCED_NOT_AVAILABLE.\n\nSTEP 6b - Rename error message slugs checked in code.\nIf you branch on the message field instead of code, these changed too:\n  receiver_not_found            -> customer_not_found\n  receiver_id_not_found         -> customer_id_not_found\n  receiver_already_approved     -> customer_already_approved\n  receiver_kyc_not_approved     -> customer_kyc_not_approved\n  receiver_not_approved         -> customer_not_approved\n  receiver_limit_not_found      -> customer_limit_not_found\n  receiver_already_has_limit_increase_in_review\n    -> customer_already_has_limit_increase_in_review\n  vm_invalid_receiver_data      -> vm_invalid_customer_data\n  vm_receiver_country_not_supported -> vm_customer_country_not_supported\n  vm_unsupported_receiver_type  -> vm_unsupported_customer_type\n  zenus_business_va_requires_business_receiver\n    -> zenus_business_va_requires_business_customer\n  beneficiary_name_must_match_receiver_for_first_party\n    -> beneficiary_name_must_match_customer_for_first_party\n  blockchain_wallet_does_not_belong_to_receiver\n    -> blockchain_wallet_does_not_belong_to_customer\n  sender_and_receiver_networks_must_be_the_same\n    -> sender_and_customer_networks_must_be_the_same\n  sender_and_receiver_tokens_must_be_the_same\n    -> sender_and_customer_tokens_must_be_the_same\nLeave unchanged: any slug mentioning receiver_amount, and\notc_only_supported_for_sender_without_cover_fees_and_receiver_with_cover_fees.\n\nSTEP 6c - Do NOT change the currency_type request value.\ncurrency_type still accepts 'sender' and 'receiver'. Sending 'customer' is\ninvalid. This pairs with the receiver_amount exception in step 4.\n\nSTEP 7 - Update the SDK accessor, if you use an official SDK.\n  blindpay.receivers.*  ->  blindpay.customers.*\n  blindpay.receivers.bankAccounts.create(...)\n    ->  blindpay.customers.bankAccounts.create(...)\nMethod signatures are identical; only the accessor renames. Bump to the latest\nrelease of your current major, which added customers with no import changes.\n\nSTEP 8 - Do NOT touch stored IDs.\nCustomer IDs keep the re_ prefix (re_abc123456789). Leave every stored ID,\nfixture, and database value exactly as it is. There is no data migration.\n\nSTEP 9 - Verify.\n  - grep the repo: no receivers, receiver_id, or receiver.* webhook names left\n  - confirm receiver_amount is still present and untouched wherever it was before\n  - run the test suite, and update fixtures or cassettes that assert on renamed\n    fields\n  - check logs for 301 responses from api.blindpay.com; each one is a path you\n    missed\n\nReport anything ambiguous rather than guessing.\n",[58,5023,5021],{"__ignoreMap":117},[16,5025,3445],{"id":3444},[1181,5027,5028,5042,5048,5066,5072,5081],{},[24,5029,5030,5031,3467,5033,5035,5036,5038,5039,420],{},"Update API paths from ",[58,5032,3022],{},[58,5034,3026],{},", including the ",[58,5037,4309],{}," invite-flow variants and ",[58,5040,5041],{},"external-customer-token",[24,5043,5044,5045,5047],{},"Rename request and response fields per the table above, leaving ",[58,5046,4559],{}," alone.",[24,5049,5050,5051,5053,5054,3467,5057,92,5060,5053,5062,3467,5064,420],{},"Update error handling: ",[58,5052,58],{}," comparisons from ",[58,5055,5056],{},"RECEIVERS_*",[58,5058,5059],{},"CUSTOMERS_*",[58,5061,4752],{},[58,5063,4220],{},[58,5065,4224],{},[24,5067,5068,5069,5071],{},"Subscribe to ",[58,5070,3237],{}," webhooks in the dashboard and update your handlers.",[24,5073,5074,5075,5077,5078,420],{},"Update your SDK to the latest release of its current major, then switch ",[58,5076,3536],{}," calls to ",[58,5079,5080],{},"customers.*",[24,5082,5083,5084,5086],{},"Leave stored IDs untouched. The ",[58,5085,3053],{}," prefix is permanent.",[12,5088,5089,5090,80,5092,5094],{},"If you completed the migration before July 3, 2026, the only new work is step 3, the error ",[58,5091,58],{},[58,5093,4752],{}," renames, which ship with this release.",[16,5096,3603],{"id":3602},[21,5098,5099,5109,5116,5122,5127,5141,5151,5160,5166],{},[24,5100,5101,5102,5104,5105,5108],{},"Logs show zero ",[58,5103,4993],{}," responses from ",[58,5106,5107],{},"api.blindpay.com",", since each one is an unmigrated path",[24,5110,3611,5111,80,5113],{},[58,5112,3614],{},[58,5114,5115],{},"\u002Fv1\u002Fe\u002Finstances\u002F*\u002Freceivers*",[24,5117,5118,5119,5121],{},"No code path reads ",[58,5120,3636],{}," or any other renamed field",[24,5123,5124,5126],{},[58,5125,4559],{}," is still read correctly on quotes, payins, payouts, and transfers",[24,5128,5129,5130,5132,5133,5135,5136,5132,5138,5140],{},"No code path compares an error ",[58,5131,58],{}," against a ",[58,5134,5056],{}," value, or an error ",[58,5137,4752],{},[58,5139,4220],{}," slug",[24,5142,5143,5144,5147,5148],{},"Requests still send ",[58,5145,5146],{},"currency_type: 'receiver'",", not ",[58,5149,5150],{},"'customer'",[24,5152,3624,5153,88,5155,92,5157,5159],{},[58,5154,3207],{},[58,5156,3217],{},[58,5158,3225],{},", and the dashboard subscription lists them",[24,5161,5162,5163,5165],{},"SDK updated, with no remaining ",[58,5164,3536],{}," accessor calls",[24,5167,3642,5168],{},[58,5169,3645],{},[16,5171,3649],{"id":3648},[1281,5173,5175],{"id":5174},"what-breaks-if-i-do-nothing","What breaks if I do nothing?",[12,5177,5178,5179,5181,5182,88,5184,88,5186,5188,5189,5191,5192,5194,5195,5198,5199,3293,5201,5203,5204,3293,5206,5208],{},"Requests keep working through the ",[58,5180,4993],{}," redirects, at the cost of an extra round-trip per call, as long as your HTTP client follows redirects (browsers, ",[58,5183,3667],{},[58,5185,3670],{},[58,5187,3673],{},", the official SDKs, and Postman all do by default). Three things break outright: ",[58,5190,3242],{}," webhook subscriptions go silent, code that reads a renamed ",[58,5193,4220],{}," response field gets ",[58,5196,5197],{},"undefined",", and error handling that branches on a ",[58,5200,5056],{},[58,5202,58],{}," or a ",[58,5205,4220],{},[58,5207,4752],{}," stops matching.",[1281,5210,3697],{"id":3696},[12,5212,3700,5213,5215,5216,80,5218,5220],{},[58,5214,3053],{}," prefix, and both ",[58,5217,3109],{},[58,5219,108],{}," carry the same value. We renamed the API surface, not the underlying resource.",[1281,5222,5224,5225,5227],{"id":5223},"why-does-receiver_amount-keep-its-name","Why does ",[58,5226,4559],{}," keep its name?",[12,5229,5230,5231,5234,5235,5238],{},"Because it does not refer to the customer resource. On a quote or a payment it means the amount landing on the receiving side, the counterpart to ",[58,5232,5233],{},"sender_amount",". Renaming it to ",[58,5236,5237],{},"customer_amount"," would have made it read like a property of the customer record.",[1281,5240,5242],{"id":5241},"will-a-find-and-replace-work","Will a find-and-replace work?",[12,5244,5245,5246,5248,5249,5251,5252,5254],{},"Not safely. ",[58,5247,4559],{}," must survive untouched while ",[58,5250,4482],{}," must change, and stored ",[58,5253,3053],{}," IDs must not be rewritten. Use the agent prompt above, which encodes those exceptions, or do the renames field by field.",[1281,5256,3712],{"id":3711},[12,5258,3715,5259,3720,5261,5263,5264,3728],{},[46,5260,3719],{"href":3718},[58,5262,3723],{}," in the subject. Including the request ID from the response (",[58,5265,3727],{},{"title":117,"searchDepth":118,"depth":118,"links":5267},[5268,5269,5270,5273,5274,5275,5276,5277,5278,5279,5280],{"id":4228,"depth":118,"text":4229},{"id":4324,"depth":118,"text":4325},{"id":4344,"depth":118,"text":4345,"children":5271},[5272],{"id":4553,"depth":1417,"text":4554},{"id":4592,"depth":118,"text":4593},{"id":4745,"depth":118,"text":4746},{"id":4976,"depth":118,"text":4977},{"id":4997,"depth":118,"text":4998},{"id":5013,"depth":118,"text":5014},{"id":3444,"depth":118,"text":3445},{"id":3602,"depth":118,"text":3603},{"id":3648,"depth":118,"text":3649,"children":5281},[5282,5283,5284,5286,5287],{"id":5174,"depth":1417,"text":5175},{"id":3696,"depth":1417,"text":3697},{"id":5223,"depth":1417,"text":5285},"Why does receiver_amount keep its name?",{"id":5241,"depth":1417,"text":5242},{"id":3711,"depth":1417,"text":3712},"2026-07-27","Final call: \u002Freceivers paths will start answering 301, receiver.* webhooks will stop firing, and receiver_* fields plus receiver error codes and messages are renamed. Full field-by-field guide and an AI migration prompt inside.",{"excerpt":5291},{"type":9,"value":5292},[5293,5297],[12,5294,4207,5295,4211],{},[46,5296,4210],{"href":3759},[12,5298,5299,4217,5301,4221,5303,4225],{},[41,5300,4216],{},[58,5302,4220],{},[58,5304,4224],{},"\u002Fchangelog\u002F2026-07-27-customers-rename-sunset","---\ntitle: '\"Receivers\" to \"Customers\" migration: final notice and complete guide'\ndescription: 'Final call: \u002Freceivers paths will start answering 301, receiver.* webhooks will stop firing, and receiver_* fields plus receiver error codes and messages are renamed. Full field-by-field guide and an AI migration prompt inside.'\ndate: 2026-07-27\ncategory: Migration\ncategoryType: update\nisChangelog: true\n---\n\nThe transition period announced in the [June 4 changelog](\u002Fchangelog\u002F2026-06-04-customers-rename) has ended, and the final release that makes \"customers\" the only name across the BlindPay platform is about to roll out. This post is the complete guide to everything that changes.\n\n**Timing: the renames below are not live yet.** They ship with the final release, which will be announced on this changelog. Until then, the `receiver_*` request fields remain the accepted shape on the current API (sending `customer_*` request fields today is rejected). Use this guide, and the AI prompt at the end, to prepare your migration diff now, and deploy it when the release goes live.\n\n\u003C!--more-->\n\n## Endpoints\n\nEvery legacy `\u002Freceivers` path now returns `301 Moved Permanently` pointing at its `\u002Fcustomers` equivalent.\n\n| Was | Now |\n| --- | --- |\n| `\u002Fv1\u002Finstances\u002F{id}\u002Freceivers[\u002F...]` | `\u002Fv1\u002Finstances\u002F{id}\u002Fcustomers[\u002F...]` |\n| `\u002Fv1\u002Fe\u002Finstances\u002F{id}\u002Freceivers[\u002F...]` | `\u002Fv1\u002Fe\u002Finstances\u002F{id}\u002Fcustomers[\u002F...]` |\n| `\u002Fv1\u002Finstances\u002F{id}\u002Flimits\u002Freceivers\u002F{id}` | `\u002Fv1\u002Finstances\u002F{id}\u002Flimits\u002Fcustomers\u002F{id}` |\n| `\u002Fv1\u002Finstances\u002F{id}\u002Fexternal-receiver-token` | `\u002Fv1\u002Finstances\u002F{id}\u002Fexternal-customer-token` |\n\nThis covers the customer collection and item routes plus every sub-resource: bank accounts, wallets, blockchain wallets, virtual accounts, offramp wallets, limits, limit increases, and RFIs. The `\u002Fe\u002F` external invite-flow variants redirect too.\n\nNote that `external-receiver-token` is renamed even though it has no `\u002Freceivers\u002F` path segment.\n\n## Webhooks\n\n`receiver.new`, `receiver.update`, and `receiver.delete` no longer fire. Subscribe to `customer.new`, `customer.update`, and `customer.delete` instead; they carry the same payloads. The dual-emit behavior from the transition window is gone, so you now receive exactly one event per action.\n\n## Renamed fields\n\n| Was | Now | Where |\n| --- | --- | --- |\n| `receiver_id` | `customer_id` | Payins, payouts, quotes, transfers, bank accounts, wallets, blockchain wallets, virtual accounts, offramp wallets, limit increases, RFIs, TOS. Also the path segment and list filter. |\n| `receiver_name` | `customer_name` | Customer list filter query parameter |\n| `receiver_local_amount` | `customer_local_amount` | Quotes, payouts |\n| `receiver_wallet_address` | `customer_wallet_address` | Transfers, transfer quotes |\n| `receiver_network` | `customer_network` | Transfers, transfer quotes |\n| `receiver_token` | `customer_token` | Transfers, transfer quotes |\n| `receiver_invite_redirect_url` | `customer_invite_redirect_url` | Instance settings |\n| `receiver_rfi_emails_enabled` | `customer_rfi_emails_enabled` | Instance settings |\n| `receivers_amount` | `customers_amount` | `GET \u002Fv1\u002Finstances`, the count of customers on the instance |\n| `receiver_type` | `customer_type` | RFI |\n| `receiver_kyc_status` | `customer_kyc_status` | RFI |\n| `receiver_aiprise_session_id` | `customer_aiprise_session_id` | RFI |\n| `receiver_aiprise_user_profile_id` | `customer_aiprise_user_profile_id` | RFI |\n\n### The one field that keeps its name\n\n`receiver_amount` is **not** renamed. It stays `receiver_amount` on quotes, payins, payouts, and transfers, because there it means \"the amount the receiving side gets\", a leg of the transaction rather than a reference to the customer resource.\n\nDo not confuse it with `receivers_amount` (plural), which **is** renamed to `customers_amount`. That one is the customer count on an instance.\n\nThis is the single reason a blind find-and-replace of `receiver` to `customer` will break your integration.\n\n## Renamed error codes\n\nThe `code` field on error responses is a stable identifier meant for programmatic handling, and eleven of them changed prefix.\n\n| Was | Now |\n| --- | --- |\n| `RECEIVERS_NOT_FOUND` | `CUSTOMERS_NOT_FOUND` |\n| `RECEIVERS_ALREADY_APPROVED` | `CUSTOMERS_ALREADY_APPROVED` |\n| `RECEIVERS_KYC_NOT_APPROVED` | `CUSTOMERS_KYC_NOT_APPROVED` |\n| `RECEIVERS_ONBOARDING_INCOMPLETE` | `CUSTOMERS_ONBOARDING_INCOMPLETE` |\n| `RECEIVERS_INVALID_DATA` | `CUSTOMERS_INVALID_DATA` |\n| `RECEIVERS_INVALID_PHONE` | `CUSTOMERS_INVALID_PHONE` |\n| `RECEIVERS_INVALID_TAX_ID` | `CUSTOMERS_INVALID_TAX_ID` |\n| `RECEIVERS_ID_DOCUMENT_INVALID` | `CUSTOMERS_ID_DOCUMENT_INVALID` |\n| `RECEIVERS_COUNTRY_NOT_SUPPORTED` | `CUSTOMERS_COUNTRY_NOT_SUPPORTED` |\n| `RECEIVERS_ENHANCED_KYC_REQUIRED` | `CUSTOMERS_ENHANCED_KYC_REQUIRED` |\n| `RECEIVERS_BUSINESS_ENHANCED_NOT_AVAILABLE` | `CUSTOMERS_BUSINESS_ENHANCED_NOT_AVAILABLE` |\n\n## Renamed error messages\n\nThe legacy `message` slug also changed on the errors below. If you branch on `message` rather than `code`, update both.\n\n| Was | Now |\n| --- | --- |\n| `receiver_not_found` | `customer_not_found` |\n| `receiver_id_not_found` | `customer_id_not_found` |\n| `receiver_already_approved` | `customer_already_approved` |\n| `receiver_kyc_not_approved` | `customer_kyc_not_approved` |\n| `receiver_not_approved` | `customer_not_approved` |\n| `receiver_limit_not_found` | `customer_limit_not_found` |\n| `receiver_already_has_limit_increase_in_review` | `customer_already_has_limit_increase_in_review` |\n| `vm_invalid_receiver_data` | `vm_invalid_customer_data` |\n| `vm_receiver_country_not_supported` | `vm_customer_country_not_supported` |\n| `vm_unsupported_receiver_type` | `vm_unsupported_customer_type` |\n| `zenus_business_va_requires_business_receiver` | `zenus_business_va_requires_business_customer` |\n| `beneficiary_name_must_match_receiver_for_first_party` | `beneficiary_name_must_match_customer_for_first_party` |\n| `blockchain_wallet_does_not_belong_to_receiver` | `blockchain_wallet_does_not_belong_to_customer` |\n| `sender_and_receiver_networks_must_be_the_same` | `sender_and_customer_networks_must_be_the_same` |\n| `sender_and_receiver_tokens_must_be_the_same` | `sender_and_customer_tokens_must_be_the_same` |\n\nTwo `message` slugs are deliberately unchanged, because they describe the receiving leg of a transaction rather than the customer resource: `otc_only_supported_for_sender_without_cover_fees_and_receiver_with_cover_fees`, and every slug involving `receiver_amount`. The `currency_type` request enum also keeps its `sender` and `receiver` values.\n\n## Deprecation headers are gone\n\n`\u002Freceivers` responses no longer carry `Deprecation: true`, `Sunset`, or `Link: rel=\"successor-version\"`. If you set up the CI smoke test suggested in the June changelog, it now passes trivially instead of catching anything. Replace it with a check that asserts no `301` responses from BlindPay.\n\n## IDs are unchanged\n\nCustomer IDs keep the `re_` prefix, and customer records keep both `id` and its canonical alias `customer_id`. No data migration is needed. Do not rewrite stored IDs.\n\n## Migrate your code with an AI agent\n\nIf you use an AI coding agent (Claude Code, Codex, Cursor, Windsurf, or similar), paste the prompt below into it from the root of your integration. It contains every rename from this changelog and the June announcement, including the exceptions that make a naive find-and-replace unsafe.\n\n```text\nMigrate this codebase off the deprecated BlindPay \"receivers\" API surface and onto\n\"customers\". This is a rename of the API surface only: resource IDs are unchanged.\n\nWork through the steps in order and show me a diff before applying anything.\n\nSTEP 1 - Find every call site.\nSearch the whole repo (including tests, fixtures, recorded HTTP cassettes, env\nfiles, OpenAPI\u002FPostman collections, infrastructure config, and docs) for:\n  receivers, receiver_, receiverId, RECEIVERS_, \"receiver.\" (webhook event names)\n\nSTEP 2 - Rewrite URL paths.\n  \u002Fv1\u002Finstances\u002F{id}\u002Freceivers               -> \u002Fv1\u002Finstances\u002F{id}\u002Fcustomers\n  \u002Fv1\u002Fe\u002Finstances\u002F{id}\u002Freceivers             -> \u002Fv1\u002Fe\u002Finstances\u002F{id}\u002Fcustomers\n  \u002Fv1\u002Finstances\u002F{id}\u002Flimits\u002Freceivers\u002F{rid}  -> \u002Fv1\u002Finstances\u002F{id}\u002Flimits\u002Fcustomers\u002F{rid}\n  \u002Fv1\u002Finstances\u002F{id}\u002Fexternal-receiver-token -> \u002Fv1\u002Finstances\u002F{id}\u002Fexternal-customer-token\nApply to all sub-resources as well: bank-accounts, wallets, blockchain-wallets,\nvirtual-accounts, offramp-wallets, limit-increase, rfi.\nThe old paths still answer 301, so nothing breaks immediately, but every call\ncosts an extra round-trip until this is done.\n\nSTEP 3 - Rename request and response fields.\n  receiver_id                      -> customer_id\n  receiver_name                    -> customer_name\n  receiver_local_amount            -> customer_local_amount\n  receiver_wallet_address          -> customer_wallet_address\n  receiver_network                 -> customer_network\n  receiver_token                   -> customer_token\n  receiver_invite_redirect_url     -> customer_invite_redirect_url\n  receiver_rfi_emails_enabled      -> customer_rfi_emails_enabled\n  receivers_amount                 -> customers_amount\n  receiver_type                    -> customer_type\n  receiver_kyc_status              -> customer_kyc_status\n  receiver_aiprise_session_id      -> customer_aiprise_session_id\n  receiver_aiprise_user_profile_id -> customer_aiprise_user_profile_id\n\nSTEP 4 - CRITICAL EXCEPTION. Do NOT rename receiver_amount.\nreceiver_amount (singular) is still called receiver_amount on quotes, payins,\npayouts, and transfers. It means \"amount the receiving side gets\", not a\nreference to the customer resource. Renaming it will break those calls.\nNote the near-miss: receivers_amount (plural, the customer count on\nGET \u002Fv1\u002Finstances) IS renamed to customers_amount. Handle each explicitly.\nNever run a blanket s\u002Freceiver\u002Fcustomer\u002F over this repo.\n\nSTEP 5 - Rename webhook event names and handlers.\n  receiver.new    -> customer.new\n  receiver.update -> customer.update\n  receiver.delete -> customer.delete\nPayloads are identical. Also update the subscription list in the BlindPay\ndashboard; a code-only change will leave your endpoint silent.\nThe old dual-emit is gone, so if a handler was de-duplicating receiver.* against\ncustomer.* for the same action, that workaround can be removed.\n\nSTEP 6 - Rename error codes checked in code.\nAny comparison against the code field on an error response:\n  RECEIVERS_NOT_FOUND -> CUSTOMERS_NOT_FOUND, and the same CUSTOMERS_ prefix\n  swap for ALREADY_APPROVED, KYC_NOT_APPROVED, ONBOARDING_INCOMPLETE,\n  INVALID_DATA, INVALID_PHONE, INVALID_TAX_ID, ID_DOCUMENT_INVALID,\n  COUNTRY_NOT_SUPPORTED, ENHANCED_KYC_REQUIRED,\n  BUSINESS_ENHANCED_NOT_AVAILABLE.\n\nSTEP 6b - Rename error message slugs checked in code.\nIf you branch on the message field instead of code, these changed too:\n  receiver_not_found            -> customer_not_found\n  receiver_id_not_found         -> customer_id_not_found\n  receiver_already_approved     -> customer_already_approved\n  receiver_kyc_not_approved     -> customer_kyc_not_approved\n  receiver_not_approved         -> customer_not_approved\n  receiver_limit_not_found      -> customer_limit_not_found\n  receiver_already_has_limit_increase_in_review\n    -> customer_already_has_limit_increase_in_review\n  vm_invalid_receiver_data      -> vm_invalid_customer_data\n  vm_receiver_country_not_supported -> vm_customer_country_not_supported\n  vm_unsupported_receiver_type  -> vm_unsupported_customer_type\n  zenus_business_va_requires_business_receiver\n    -> zenus_business_va_requires_business_customer\n  beneficiary_name_must_match_receiver_for_first_party\n    -> beneficiary_name_must_match_customer_for_first_party\n  blockchain_wallet_does_not_belong_to_receiver\n    -> blockchain_wallet_does_not_belong_to_customer\n  sender_and_receiver_networks_must_be_the_same\n    -> sender_and_customer_networks_must_be_the_same\n  sender_and_receiver_tokens_must_be_the_same\n    -> sender_and_customer_tokens_must_be_the_same\nLeave unchanged: any slug mentioning receiver_amount, and\notc_only_supported_for_sender_without_cover_fees_and_receiver_with_cover_fees.\n\nSTEP 6c - Do NOT change the currency_type request value.\ncurrency_type still accepts 'sender' and 'receiver'. Sending 'customer' is\ninvalid. This pairs with the receiver_amount exception in step 4.\n\nSTEP 7 - Update the SDK accessor, if you use an official SDK.\n  blindpay.receivers.*  ->  blindpay.customers.*\n  blindpay.receivers.bankAccounts.create(...)\n    ->  blindpay.customers.bankAccounts.create(...)\nMethod signatures are identical; only the accessor renames. Bump to the latest\nrelease of your current major, which added customers with no import changes.\n\nSTEP 8 - Do NOT touch stored IDs.\nCustomer IDs keep the re_ prefix (re_abc123456789). Leave every stored ID,\nfixture, and database value exactly as it is. There is no data migration.\n\nSTEP 9 - Verify.\n  - grep the repo: no receivers, receiver_id, or receiver.* webhook names left\n  - confirm receiver_amount is still present and untouched wherever it was before\n  - run the test suite, and update fixtures or cassettes that assert on renamed\n    fields\n  - check logs for 301 responses from api.blindpay.com; each one is a path you\n    missed\n\nReport anything ambiguous rather than guessing.\n```\n\n## What you need to do\n\n1. Update API paths from `\u002Freceivers` to `\u002Fcustomers`, including the `\u002Fe\u002F` invite-flow variants and `external-customer-token`.\n2. Rename request and response fields per the table above, leaving `receiver_amount` alone.\n3. Update error handling: `code` comparisons from `RECEIVERS_*` to `CUSTOMERS_*`, and `message` comparisons from `receiver_*` to `customer_*`.\n4. Subscribe to `customer.*` webhooks in the dashboard and update your handlers.\n5. Update your SDK to the latest release of its current major, then switch `receivers.*` calls to `customers.*`.\n6. Leave stored IDs untouched. The `re_` prefix is permanent.\n\nIf you completed the migration before July 3, 2026, the only new work is step 3, the error `code` and `message` renames, which ship with this release.\n\n## Verification checklist\n\n- Logs show zero `301` responses from `api.blindpay.com`, since each one is an unmigrated path\n- Logs show zero requests to `\u002Fv1\u002Finstances\u002F*\u002Freceivers*` and `\u002Fv1\u002Fe\u002Finstances\u002F*\u002Freceivers*`\n- No code path reads `response.receiver_id` or any other renamed field\n- `receiver_amount` is still read correctly on quotes, payins, payouts, and transfers\n- No code path compares an error `code` against a `RECEIVERS_*` value, or an error `message` against a `receiver_*` slug\n- Requests still send `currency_type: 'receiver'`, not `'customer'`\n- Webhook handlers process `customer.new`, `customer.update`, and `customer.delete`, and the dashboard subscription lists them\n- SDK updated, with no remaining `receivers.*` accessor calls\n- Saved dashboard URLs use `\u002Fcustomers\u002F`\n\n## FAQ\n\n### What breaks if I do nothing?\n\nRequests keep working through the `301` redirects, at the cost of an extra round-trip per call, as long as your HTTP client follows redirects (browsers, `curl`, `requests`, `axios`, the official SDKs, and Postman all do by default). Three things break outright: `receiver.*` webhook subscriptions go silent, code that reads a renamed `receiver_*` response field gets `undefined`, and error handling that branches on a `RECEIVERS_*` `code` or a `receiver_*` `message` stops matching.\n\n### Do I need to migrate my stored IDs?\n\nNo. All IDs keep the `re_` prefix, and both `id` and `customer_id` carry the same value. We renamed the API surface, not the underlying resource.\n\n### Why does `receiver_amount` keep its name?\n\nBecause it does not refer to the customer resource. On a quote or a payment it means the amount landing on the receiving side, the counterpart to `sender_amount`. Renaming it to `customer_amount` would have made it read like a property of the customer record.\n\n### Will a find-and-replace work?\n\nNot safely. `receiver_amount` must survive untouched while `receivers_amount` must change, and stored `re_` IDs must not be rewritten. Use the agent prompt above, which encodes those exceptions, or do the renames field by field.\n\n### How do I report issues with the migration?\n\nUse the feedback button in the dashboard (under your profile dropdown) or email support@blindpay.com with `migration` in the subject. Including the request ID from the response (`x-blindpay-request-id` header) speeds up the lookup.\n",{"title":4202,"description":5289},"changelog\u002F2026-07-27-customers-rename-sunset","9Iyn8CZpVkt5-1Dgpeb5cBtivgEXER0vaAmW-3piEBI",1785804331490]