[{"data":1,"prerenderedAt":1463},["ShallowReactive",2],{"content-\u002Fresources\u002Fmore\u002Fhow-to-test-virtual-accounts-sandbox":3,"resources-category-how-to-test-virtual-accounts-sandbox":1180},{"id":4,"title":5,"authors":6,"body":7,"categories":6,"category":1126,"categoryType":6,"compare":6,"contributors":6,"date":1127,"description":1128,"extension":1129,"faq":1130,"howto":1146,"isBlog":1170,"isChangelog":1170,"meta":1171,"navigation":1173,"path":1174,"pillar":1170,"products":6,"rawbody":1175,"role":6,"seo":1176,"seoTitle":1177,"stem":1178,"thumbnail":6,"updated":6,"__hash__":1179},"content\u002Fresources\u002Fmore\u002Fhow-to-test-virtual-accounts-sandbox.md","How to test a virtual accounts API integration before going live",null,{"type":8,"value":9,"toc":1114},"minimark",[10,14,17,22,38,42,45,48,118,130,137,141,144,248,251,399,418,422,425,562,569,573,583,770,782,795,799,802,896,909,913,920,926,965,981,996,999,1003,1006,1044,1047,1051,1058,1084,1091,1095,1105,1110],[11,12,13],"p",{},"To test a virtual accounts API integration, run the whole sequence on a development instance: create a customer, fill the compliance fields, link a wallet, create the account, and simulate deposits that complete, fail, and refund. Check every status and webhook along the way. Then plan for what a sandbox can't test: bank review, real payer banks, and name checks.",[11,15,16],{},"The sandbox proves your code. It doesn't prove your approval timeline.",[18,19,21],"h2",{"id":20},"key-takeaways","Key takeaways",[23,24,25,29,32,35],"ul",{},[26,27,28],"li",{},"A virtual accounts integration is seven steps, and only one of them is the create call. The rest is compliance fields and webhooks.",[26,30,31],{},"A sandbox simulates approval and deposits. It can't simulate bank review, the payer's bank, or a beneficiary name check.",[26,33,34],{},"In production you never create the payins for deposits. Each deposit creates one, so your handler has to accept payins it has never seen.",[26,36,37],{},"Model one account per customer. Pooled accounts push matching back onto payers, and per-invoice accounts run into review limits and nesting rules.",[18,39,41],{"id":40},"what-does-a-virtual-accounts-api-integration-involve","What does a virtual accounts API integration involve?",[11,43,44],{},"A virtual accounts integration takes a verified customer, gives them their own bank account details, and turns every deposit into a tracked event. The create call is one request. The work around it is customer data, a settlement destination, and webhook handling.",[11,46,47],{},"The sequence at BlindPay looks like this:",[49,50,51,58,64,75,81,95,112],"ol",{},[26,52,53,57],{},[54,55,56],"strong",{},"Create the customer."," Individual or business. On development, KYC is auto-approved.",[26,59,60,63],{},[54,61,62],{},"Fill the compliance fields."," Account purpose and source of wealth for everyone. For businesses, also business type, description, NAICS industry code, estimated annual revenue, publicly traded status, and owners with ownership percentage and title.",[26,65,66,69,70,74],{},[54,67,68],{},"Add the settlement wallet."," A blockchain wallet (",[71,72,73],"code",{},"bw_...",") the customer controls. Deposits settle there.",[26,76,77,80],{},[54,78,79],{},"Create the virtual account."," One request with the banking partner, the token, and the wallet id.",[26,82,83,86,87,90,91,94],{},[54,84,85],{},"Handle the account webhooks."," ",[71,88,89],{},"virtualAccount.new"," fires when the account is requested, ",[71,92,93],{},"virtualAccount.complete"," when the bank approves it and the numbers are issued.",[26,96,97,86,100,103,104,107,108,111],{},[54,98,99],{},"Handle one payin per deposit.",[71,101,102],{},"payin.new",", then intermediate ",[71,105,106],{},"payin.update"," events, then ",[71,109,110],{},"payin.complete",".",[26,113,114,117],{},[54,115,116],{},"Switch to production."," New instance, new key, new webhook endpoint, real tokens.",[11,119,120,121,124,125,111],{},"Step 2 is where teams lose days. Depending on the banking partner, the API rejects the create request with ",[71,122,123],{},"missing_required_fields"," and names each blank field. Collect those fields in your onboarding form, not in a support thread later. The full list is in ",[126,127,129],"a",{"href":128},"\u002Fresources\u002Fmore\u002Fvirtual-account-requirements-kyc-kyb","virtual account requirements",[11,131,132,133,111],{},"If you're still deciding what a virtual account is for in your product, start with ",[126,134,136],{"href":135},"\u002Fresources\u002Fmore\u002Fwhat-is-a-virtual-account","what is a virtual account",[18,138,140],{"id":139},"what-do-the-create-request-and-response-look-like","What do the create request and response look like?",[11,142,143],{},"The request names the banking partner, the settlement token, and the wallet. The response returns an account id and, once approved, routing and account numbers per rail. Here's an example on a development instance, with placeholder ids:",[145,146,151],"pre",{"className":147,"code":148,"language":149,"meta":150,"style":150},"language-bash shiki shiki-themes github-light","curl --request POST \\\n  --url https:\u002F\u002Fapi.blindpay.com\u002Fv1\u002Finstances\u002Fin_000000000000\u002Fcustomers\u002Fre_000000000000\u002Fvirtual-accounts \\\n  --header 'Authorization: Bearer YOUR_API_KEY' \\\n  --header 'Content-Type: application\u002Fjson' \\\n  --header 'Idempotency-Key: 6f1c2a9e-onboarding-re_000000000000' \\\n  --data '{\n    \"banking_partner\": \"\u003Celigible_banking_partner>\",\n    \"token\": \"USDB\",\n    \"blockchain_wallet_id\": \"bw_000000000000\"\n  }'\n","bash","",[71,152,153,173,184,195,205,215,224,230,236,242],{"__ignoreMap":150},[154,155,158,162,166,170],"span",{"class":156,"line":157},"line",1,[154,159,161],{"class":160},"s7eDp","curl",[154,163,165],{"class":164},"sYu0t"," --request",[154,167,169],{"class":168},"sYBdl"," POST",[154,171,172],{"class":164}," \\\n",[154,174,176,179,182],{"class":156,"line":175},2,[154,177,178],{"class":164},"  --url",[154,180,181],{"class":168}," https:\u002F\u002Fapi.blindpay.com\u002Fv1\u002Finstances\u002Fin_000000000000\u002Fcustomers\u002Fre_000000000000\u002Fvirtual-accounts",[154,183,172],{"class":164},[154,185,187,190,193],{"class":156,"line":186},3,[154,188,189],{"class":164},"  --header",[154,191,192],{"class":168}," 'Authorization: Bearer YOUR_API_KEY'",[154,194,172],{"class":164},[154,196,198,200,203],{"class":156,"line":197},4,[154,199,189],{"class":164},[154,201,202],{"class":168}," 'Content-Type: application\u002Fjson'",[154,204,172],{"class":164},[154,206,208,210,213],{"class":156,"line":207},5,[154,209,189],{"class":164},[154,211,212],{"class":168}," 'Idempotency-Key: 6f1c2a9e-onboarding-re_000000000000'",[154,214,172],{"class":164},[154,216,218,221],{"class":156,"line":217},6,[154,219,220],{"class":164},"  --data",[154,222,223],{"class":168}," '{\n",[154,225,227],{"class":156,"line":226},7,[154,228,229],{"class":168},"    \"banking_partner\": \"\u003Celigible_banking_partner>\",\n",[154,231,233],{"class":156,"line":232},8,[154,234,235],{"class":168},"    \"token\": \"USDB\",\n",[154,237,239],{"class":156,"line":238},9,[154,240,241],{"class":168},"    \"blockchain_wallet_id\": \"bw_000000000000\"\n",[154,243,245],{"class":156,"line":244},10,[154,246,247],{"class":168},"  }'\n",[11,249,250],{},"An abbreviated response, with values a development instance returns:",[145,252,256],{"className":253,"code":254,"language":255,"meta":150,"style":150},"language-json shiki shiki-themes github-light","{\n  \"id\": \"va_000000000000\",\n  \"kyc_status\": \"approved\",\n  \"token\": \"USDB\",\n  \"blockchain_wallet_id\": \"bw_000000000000\",\n  \"partner_fee_id\": null,\n  \"us\": {\n    \"ach\": { \"routing_number\": \"110000000\", \"account_number\": \"123456789012\" },\n    \"wire\": { \"routing_number\": \"110000000\", \"account_number\": \"123456789012\" }\n  }\n}\n","json",[71,257,258,264,278,290,302,314,326,334,364,388,393],{"__ignoreMap":150},[154,259,260],{"class":156,"line":157},[154,261,263],{"class":262},"sgsFI","{\n",[154,265,266,269,272,275],{"class":156,"line":175},[154,267,268],{"class":164},"  \"id\"",[154,270,271],{"class":262},": ",[154,273,274],{"class":168},"\"va_000000000000\"",[154,276,277],{"class":262},",\n",[154,279,280,283,285,288],{"class":156,"line":186},[154,281,282],{"class":164},"  \"kyc_status\"",[154,284,271],{"class":262},[154,286,287],{"class":168},"\"approved\"",[154,289,277],{"class":262},[154,291,292,295,297,300],{"class":156,"line":197},[154,293,294],{"class":164},"  \"token\"",[154,296,271],{"class":262},[154,298,299],{"class":168},"\"USDB\"",[154,301,277],{"class":262},[154,303,304,307,309,312],{"class":156,"line":207},[154,305,306],{"class":164},"  \"blockchain_wallet_id\"",[154,308,271],{"class":262},[154,310,311],{"class":168},"\"bw_000000000000\"",[154,313,277],{"class":262},[154,315,316,319,321,324],{"class":156,"line":217},[154,317,318],{"class":164},"  \"partner_fee_id\"",[154,320,271],{"class":262},[154,322,323],{"class":164},"null",[154,325,277],{"class":262},[154,327,328,331],{"class":156,"line":226},[154,329,330],{"class":164},"  \"us\"",[154,332,333],{"class":262},": {\n",[154,335,336,339,342,345,347,350,353,356,358,361],{"class":156,"line":232},[154,337,338],{"class":164},"    \"ach\"",[154,340,341],{"class":262},": { ",[154,343,344],{"class":164},"\"routing_number\"",[154,346,271],{"class":262},[154,348,349],{"class":168},"\"110000000\"",[154,351,352],{"class":262},", ",[154,354,355],{"class":164},"\"account_number\"",[154,357,271],{"class":262},[154,359,360],{"class":168},"\"123456789012\"",[154,362,363],{"class":262}," },\n",[154,365,366,369,371,373,375,377,379,381,383,385],{"class":156,"line":238},[154,367,368],{"class":164},"    \"wire\"",[154,370,341],{"class":262},[154,372,344],{"class":164},[154,374,271],{"class":262},[154,376,349],{"class":168},[154,378,352],{"class":262},[154,380,355],{"class":164},[154,382,271],{"class":262},[154,384,360],{"class":168},[154,386,387],{"class":262}," }\n",[154,389,390],{"class":156,"line":244},[154,391,392],{"class":262},"  }\n",[154,394,396],{"class":156,"line":395},11,[154,397,398],{"class":262},"}\n",[11,400,401,402,405,406,409,410,413,414,111],{},"Three details matter for your data model. The ",[71,403,404],{},"token"," and ",[71,407,408],{},"blockchain_wallet_id"," can be changed later, but ",[71,411,412],{},"banking_partner"," can't. Before approval, the rail numbers are empty, so don't render payment instructions until they exist. And USDB only works on development: production uses USDC or USDT. The field reference is in ",[126,415,417],{"href":416},"\u002Fdocs\u002Fvirtual-accounts-create","create a virtual account",[18,419,421],{"id":420},"what-does-a-development-instance-simulate-and-what-cant-it","What does a development instance simulate, and what can't it?",[11,423,424],{},"A development instance simulates approvals and deposits with the same endpoints, fields, and webhooks as production. It can't simulate anything a real bank does. That gap decides which tests belong in the sandbox and which belong in a controlled production launch.",[426,427,428,444],"table",{},[429,430,431],"thead",{},[432,433,434,438,441],"tr",{},[435,436,437],"th",{},"Behavior",[435,439,440],{},"Development instance",[435,442,443],{},"Production instance",[445,446,447,463,489,504,515,537,548],"tbody",{},[432,448,449,453,460],{},[450,451,452],"td",{},"Customer KYC",[450,454,455,456,459],{},"Auto-approved. A first or legal name of ",[71,457,458],{},"Fail"," returns a rejection",[450,461,462],{},"Real review: about 60 seconds for KYC Standard, hours to a business day for manual review",[432,464,465,468,474],{},[450,466,467],{},"Virtual account review",[450,469,470,471],{},"Skipped. Created directly as ",[71,472,473],{},"approved",[450,475,476,479,480,479,483,485,486],{},[71,477,478],{},"pending_review",", then ",[71,481,482],{},"verifying",[71,484,473],{}," or ",[71,487,488],{},"rejected",[432,490,491,494,501],{},[450,492,493],{},"Account numbers",[450,495,496,497,500],{},"Routing ",[71,498,499],{},"110000000",", fake 12-digit account number that stays the same per account",[450,502,503],{},"Real, bank-issued numbers",[432,505,506,509,512],{},[450,507,508],{},"Deposits",[450,510,511],{},"Simulated with a payin that completes in about 30 seconds",[450,513,514],{},"Real ACH, wire, or SWIFT transfer, up to 5 business days for ACH and wire",[432,516,517,520,534],{},[450,518,519],{},"Outcome control",[450,521,522,525,526,529,530,533],{},[71,523,524],{},"request_amount"," of ",[71,527,528],{},"66600"," fails, ",[71,531,532],{},"77700"," refunds",[450,535,536],{},"The real amount is processed",[432,538,539,542,545],{},[450,540,541],{},"Settlement token",[450,543,544],{},"USDB",[450,546,547],{},"USDC or USDT",[432,549,550,553,559],{},[450,551,552],{},"Rate limit",[450,554,555,556],{},"About 100 requests per minute per instance, then ",[71,557,558],{},"429",[450,560,561],{},"The development cap does not apply",[11,563,564,565,111],{},"What the sandbox can't tell you: how long bank review takes for your customer mix, whether a payer's bank adds its own delays, whether a sending bank checks the beneficiary name, and which documents the bank asks for. Those are production facts. The general list of what testing misses is in ",[126,566,568],{"href":567},"\u002Fresources\u002Fmore\u002Fstablecoin-api-sandbox-vs-production","stablecoin API sandbox vs production",[18,570,572],{"id":571},"which-test-cases-should-you-run","Which test cases should you run?",[11,574,575,576,485,579,582],{},"Run one test per status your product shows and one per webhook your ledger depends on. The table below covers the virtual account cases. Simulate each deposit with a payin quote for the customer using ",[71,577,578],{},"ach",[71,580,581],{},"wire",", then a payin created from it within the 5 minute quote window.",[426,584,585,598],{},[429,586,587],{},[432,588,589,592,595],{},[435,590,591],{},"Test",[435,593,594],{},"How to trigger it",[435,596,597],{},"Expected result",[445,599,600,616,633,649,668,679,702,720,737,755],{},[432,601,602,605,610],{},[450,603,604],{},"Customer rejected",[450,606,607,608],{},"Create a customer with first or legal name ",[71,609,458],{},[450,611,612,613,615],{},"Customer ",[71,614,488],{},". Your onboarding should block account creation",[432,617,618,621,628],{},[450,619,620],{},"Missing compliance fields",[450,622,623,624,627],{},"Request an account for a business with ",[71,625,626],{},"account_purpose"," blank",[450,629,630,632],{},[71,631,123],{}," naming each blank field, depending on the banking partner",[432,634,635,638,641],{},[450,636,637],{},"Account created",[450,639,640],{},"Valid create request",[450,642,643,645,646,648],{},[71,644,473],{}," right away, ",[71,647,89],{}," fires",[432,650,651,654,661],{},[450,652,653],{},"Retried create",[450,655,656,657,660],{},"Resend the same request with the same ",[71,658,659],{},"Idempotency-Key"," and identical body",[450,662,663,664,667],{},"Original response replayed with ",[71,665,666],{},"Idempotency-Replayed: true",", no second account",[432,669,670,673,676],{},[450,671,672],{},"Second account",[450,674,675],{},"Request another account for the same customer on the same banking partner",[450,677,678],{},"Rejected, except on the one partner that allows several accounts per customer",[432,680,681,684,687],{},[450,682,683],{},"Deposit completes",[450,685,686],{},"Payin with any normal amount",[450,688,689,479,691,693,694,697,698,701],{},[71,690,102],{},[71,692,110],{}," with status ",[71,695,696],{},"completed","; ",[71,699,700],{},"blindpay_bank_details"," shows the account's own numbers",[432,703,704,707,714],{},[450,705,706],{},"Deposit fails",[450,708,709,525,711,713],{},[71,710,524],{},[71,712,528],{}," ($666.00)",[450,715,716,717],{},"Status ",[71,718,719],{},"failed",[432,721,722,725,732],{},[450,723,724],{},"Deposit refunds",[450,726,727,525,729,731],{},[71,728,524],{},[71,730,532],{}," ($777.00)",[450,733,716,734],{},[71,735,736],{},"refunded",[432,738,739,742,745],{},[450,740,741],{},"Fee fields",[450,743,744],{},"Any completed deposit",[450,746,747,748,405,751,754],{},"Your ledger stores both ",[71,749,750],{},"billing_fee_amount",[71,752,753],{},"transaction_fee_amount"," without assuming either is set. Development is free, so check real values on the first production deposits",[432,756,757,760,763],{},[450,758,759],{},"Duplicate webhook",[450,761,762],{},"Replay an event from the webhook dashboard",[450,764,765,766,769],{},"Your handler deduplicates on ",[71,767,768],{},"svix-id"," and changes nothing",[11,771,772,773,777,778,111],{},"Two of these catch most production bugs. The retried create, because a timeout during onboarding is common and a second account is a support ticket. And the duplicate webhook, because replays happen. Signature checks and dedupe patterns are in ",[126,774,776],{"href":775},"\u002Fresources\u002Fmore\u002Fstablecoin-api-webhooks-reconciliation","stablecoin API webhooks",", and key handling is in ",[126,779,781],{"href":780},"\u002Fresources\u002Fmore\u002Fstablecoin-api-idempotency-keys","idempotency keys",[11,783,784,785,787,788,791,792,794],{},"One production difference changes how you write the deposit handler. In the sandbox you create the payin yourself. In production, BlindPay creates a payin for every deposit that lands on the account and sends ",[71,786,102],{},". Match it on ",[71,789,790],{},"customer_id"," and the account number in ",[71,793,700],{},", never on a payin id you stored earlier.",[18,796,798],{"id":797},"should-you-create-one-account-per-customer-per-invoice-or-a-pooled-account","Should you create one account per customer, per invoice, or a pooled account?",[11,800,801],{},"Create one account per customer. That's the model virtual accounts are built for: the receiving account number identifies who paid, and the account is reviewed once. Pooled accounts and per-invoice accounts both work in narrow cases, with real costs.",[426,803,804,819],{},[429,805,806],{},[432,807,808,810,813,816],{},[435,809],{},[435,811,812],{},"Single pooled account",[435,814,815],{},"One account per customer",[435,817,818],{},"One account per invoice",[445,820,821,835,849,863,882],{},[432,822,823,826,829,832],{},[450,824,825],{},"What the payer sees",[450,827,828],{},"A shared account plus a reference or memo code",[450,830,831],{},"The customer's own routing and account number",[450,833,834],{},"A new account number on every invoice",[432,836,837,840,843,846],{},[450,838,839],{},"How deposits are matched",[450,841,842],{},"The payer types the reference correctly",[450,844,845],{},"By the receiving account number",[450,847,848],{},"By account number, at invoice level",[432,850,851,854,857,860],{},[450,852,853],{},"Review",[450,855,856],{},"None per payment",[450,858,859],{},"Once per customer",[450,861,862],{},"Once per account, so once per invoice",[432,864,865,868,876,879],{},[450,866,867],{},"At BlindPay",[450,869,870,871,405,873,875],{},"Payin quote without a virtual account: ",[71,872,578],{},[71,874,581],{}," use a memo code, capped at $500,000 per transaction, and SWIFT isn't available",[450,877,878],{},"The default model, with SWIFT available once approved",[450,880,881],{},"Limited: a customer holds one account per banking partner, with one partner allowing several",[432,883,884,887,890,893],{},[450,885,886],{},"Main risk",[450,888,889],{},"Payers drop the reference and someone matches by hand",[450,891,892],{},"Approval time before the first deposit",[450,894,895],{},"Review per account, payers reusing old details, and nesting",[11,897,898,899,903,904,908],{},"Nesting is the reason per-invoice designs fail review. If each account really represents a different client of your customer, the money belongs to parties the provider never verified. BlindPay's rule is in ",[126,900,902],{"href":901},"\u002Fdocs\u002Fkb\u002Fnested-payments","nested payments",". For invoice-level matching on one account, use amounts and the payment records instead; ",[126,905,907],{"href":906},"\u002Fresources\u002Fmore\u002Fvirtual-account-reconciliation","how virtual accounts automate reconciliation"," walks through partial payments and overpayments.",[18,910,912],{"id":911},"what-does-a-test-plan-look-like-for-a-payroll-platform","What does a test plan look like for a payroll platform?",[11,914,915,919],{},[916,917,918],"em",{},"Illustrative example, not a real customer."," A payroll platform lets employers fund payroll by sending ACH or wire to their own virtual account, which settles to USDC before payouts go to contractors. The team writes a sandbox plan with three test employers.",[11,921,922,925],{},[54,923,924],{},"Employer A, the happy path."," A US business with every compliance field filled.",[49,927,928,937,946,956],{},[26,929,930,479,933,936],{},[71,931,932],{},"customer.new",[71,934,935],{},"blockchainWallet.new"," when the wallet is added.",[26,938,939,940,942,943,945],{},"Create the account: ",[71,941,473],{}," in the response, ",[71,944,89],{}," fires.",[26,947,948,949,479,951,953,954,111],{},"Simulate a $12,000.00 funding deposit: ",[71,950,102],{},[71,952,110],{}," about 30 seconds later, status ",[71,955,696],{},[26,957,958,959,961,962,964],{},"Confirm the ledger stores both fee fields from the payin, even though development charges no fees. In production, the fee lands in ",[71,960,750],{}," below $100.00 and in ",[71,963,753],{}," at $100.00 or more.",[11,966,967,970,971,973,974,405,976,973,978,980],{},[54,968,969],{},"Employer B, the bad deposits."," Same setup, then two payins: ",[71,972,528],{}," ends ",[71,975,719],{},[71,977,532],{},[71,979,736],{},". The team checks that the payroll run stays blocked in both cases and that the employer sees a clear \"funding returned\" state instead of a spinner.",[11,982,983,986,987,989,990,992,993,995],{},[54,984,985],{},"Employer C, the rejected customer."," Legal name ",[71,988,458],{},". KYC comes back ",[71,991,488],{},", and the onboarding screen stops before the account request. No ",[71,994,89],{}," should ever fire for this employer.",[11,997,998],{},"The plan takes an afternoon. What it doesn't cover goes into a launch checklist: the first real employer's review time, the first real ACH arrival time, and the first micro-deposit (a $0.01 test some payroll providers send), which shows up as a real payin and should be reconciled, not flagged.",[18,1000,1002],{"id":1001},"what-changes-when-you-switch-to-production","What changes when you switch to production?",[11,1004,1005],{},"Everything that touches a bank becomes real, and the approval step comes back. Plan for both before you migrate the first customer.",[23,1007,1008,1014,1020,1026,1032,1038],{},[26,1009,1010,1013],{},[54,1011,1012],{},"New instance and key."," Production instances are created in the dashboard and can take up to 3 business days to provision. Development keys don't work on them.",[26,1015,1016,1019],{},[54,1017,1018],{},"Re-create webhooks."," The development webhook endpoint doesn't carry over.",[26,1021,1022,1025],{},[54,1023,1024],{},"Real tokens."," Switch USDB to USDC or USDT. USDT needs a wallet on Polygon, Ethereum, or Solana.",[26,1027,1028,1031],{},[54,1029,1030],{},"Real review."," Accounts go through compliance and bank review, with SLAs of 24 hours or 3 to 5 business days by account type. If the bank asks for more documents, the clock restarts when you submit them.",[26,1033,1034,1037],{},[54,1035,1036],{},"Remove test amounts."," On production, $666.00 and $777.00 are just amounts.",[26,1039,1040,1043],{},[54,1041,1042],{},"Real fees."," $1.50 per month per account, plus the fee on each deposit's payin.",[11,1045,1046],{},"Build the onboarding screen around the review time, not the API response time. That's the one thing the sandbox hides.",[18,1048,1050],{"id":1049},"where-does-blindpay-fit","Where does BlindPay fit?",[11,1052,1053,1054,1057],{},"BlindPay issues US virtual accounts in your customer's name that receive ACH, wire, and SWIFT (POBO\u002FCOBO) transfers and settle to USDC or USDT in a wallet the customer controls. The free development instance uses the same base URL as production, ",[71,1055,1056],{},"https:\u002F\u002Fapi.blindpay.com",", and which environment you hit depends on the instance your API key belongs to.",[11,1059,1060,1061,1065,1066,1070,1071,1074,1075,1079,1080,111],{},"For the build itself, there's a public OpenAPI 3.1 spec, official SDKs for Node.js, Python, Go, PHP, and Swift (",[126,1062,1064],{"href":1063},"\u002Fdocs\u002Fsdks","SDKs","), and a ",[126,1067,1069],{"href":1068},"\u002Fblog\u002Fcli","CLI"," where ",[71,1072,1073],{},"blindpay virtual_accounts create"," runs the same request from a terminal. For the full evaluation beyond testing, see ",[126,1076,1078],{"href":1077},"\u002Fresources\u002Fmore\u002Fhow-to-choose-a-virtual-account-provider","how to choose a virtual account provider",", and for what the payer side costs, ",[126,1081,1083],{"href":1082},"\u002Fresources\u002Fmore\u002Fvirtual-account-fees","virtual account fees",[11,1085,1086,1087,111],{},"What BlindPay doesn't do: issue virtual IBANs, or accounts outside the US. Deposits that never show up are covered in ",[126,1088,1090],{"href":1089},"\u002Fresources\u002Fmore\u002Fvirtual-account-deposit-not-received","virtual account deposit not received",[18,1092,1094],{"id":1093},"what-to-do-next","What to do next",[11,1096,1097,1098,1100,1101,111],{},"Create a free development instance, then run the ten test cases in the table above against your own webhook endpoint, starting with the retried create and the duplicate webhook. The request reference is in ",[126,1099,417],{"href":416},", and the full sandbox behavior is in ",[126,1102,1104],{"href":1103},"\u002Fdocs\u002Flearn\u002Fsandbox-vs-production","sandbox vs production",[11,1106,1107],{},[916,1108,1109],{},"This article is for general information only and is not legal, tax, or financial advice.",[1111,1112,1113],"style",{},"html pre.shiki code .s7eDp, html code.shiki .s7eDp{--shiki-default:#6F42C1}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);}html pre.shiki code .sgsFI, html code.shiki .sgsFI{--shiki-default:#24292E}",{"title":150,"searchDepth":175,"depth":175,"links":1115},[1116,1117,1118,1119,1120,1121,1122,1123,1124,1125],{"id":20,"depth":175,"text":21},{"id":40,"depth":175,"text":41},{"id":139,"depth":175,"text":140},{"id":420,"depth":175,"text":421},{"id":571,"depth":175,"text":572},{"id":797,"depth":175,"text":798},{"id":911,"depth":175,"text":912},{"id":1001,"depth":175,"text":1002},{"id":1049,"depth":175,"text":1050},{"id":1093,"depth":175,"text":1094},"payments","2026-09-29","The integration sequence for a virtual accounts API, what a sandbox simulates and what it can't, and a test plan with the statuses and webhooks to expect.","md",[1131,1134,1137,1140,1143],{"q":1132,"a":1133},"Can I test a virtual accounts API for free?","Yes, on BlindPay. A development instance is free and exposes the same endpoints, fields, and webhooks as production. Virtual accounts are approved instantly, deposits are simulated with payins that complete in about 30 seconds, and settlement uses USDB, a test stablecoin. You only pay the $1.50 monthly account fee and deposit fees once real accounts run on a production instance.",{"q":1135,"a":1136},"How do I simulate a deposit into a virtual account in the sandbox?","There is no bank to send from on a development instance, so you simulate the deposit with a payin. Create a payin quote for the customer with ach or wire as the payment method, then create the payin from it within the 5 minute quote window. It completes after about 30 seconds unless you use a test amount that forces a failure or a refund.",{"q":1138,"a":1139},"Are sandbox virtual account numbers real?","No. On a BlindPay development instance the routing number is always 110000000 and the account number is a fake 12-digit number derived from the account id, so it stays the same across requests. No real bank recognizes either value. Never show them to a real payer. Production accounts get bank-issued numbers once the bank approves them.",{"q":1141,"a":1142},"Why does my production virtual account stay in pending_review?","Production accounts go through two reviews. The account sits in pending_review during compliance review, then verifying during bank review, then becomes approved or rejected. Issuance SLAs are 24 hours or 3 to 5 business days depending on account type. If the bank asks for more documents, the SLA clock restarts on the day you submit them.",{"q":1144,"a":1145},"Can I test a virtual account rejection in the sandbox?","Not directly. Development instances approve every virtual account, so a rejected account only happens in production. You can test a rejected customer by setting the first or legal name to Fail. For the account itself, feed your handler a stored payload with a rejected status in a unit test, so the code path exists before the first real rejection arrives.",{"name":1147,"steps":1148},"How to integrate and test a virtual accounts API",[1149,1152,1155,1158,1161,1164,1167],{"name":1150,"text":1151},"Create the customer","Create an individual or business customer with the API. On a development instance, KYC is auto-approved, and a first or legal name of Fail returns a rejection you can test against.",{"name":1153,"text":1154},"Fill the compliance fields","Before requesting an account, fill the fields the banking partner checks: account purpose, source of wealth, and for businesses the business type, description, NAICS industry code, estimated annual revenue, and owners.",{"name":1156,"text":1157},"Add the settlement wallet","Register the customer's blockchain wallet. Every deposit into the virtual account settles to this wallet. USDT settlement needs a wallet on Polygon, Ethereum, or Solana.",{"name":1159,"text":1160},"Create the virtual account","Call the virtual accounts endpoint with the banking partner, the settlement token, and the blockchain wallet id. Send an Idempotency-Key header so a retried request never creates a second account.",{"name":1162,"text":1163},"Handle the account webhooks","Listen for virtualAccount.new when the account is requested and virtualAccount.complete when the bank approves it and the routing and account numbers are issued.",{"name":1165,"text":1166},"Handle a payin per deposit","Every deposit into the account creates a payin. Handle payin.new, any payin.update, and payin.complete, and treat completed, failed, and refunded as final statuses.",{"name":1168,"text":1169},"Switch to production","Create a production instance and API key, re-create the webhook endpoint, switch USDB to USDC or USDT, submit real KYC documents, and remove any logic that relies on test amounts.",false,{"author":1172},"BlindPay Team",true,"\u002Fresources\u002Fmore\u002Fhow-to-test-virtual-accounts-sandbox","---\ntitle: \"How to test a virtual accounts API integration before going live\"\nseoTitle: \"Virtual accounts API: how to test it in a sandbox\"\ndescription: \"The integration sequence for a virtual accounts API, what a sandbox simulates and what it can't, and a test plan with the statuses and webhooks to expect.\"\ndate: \"2026-09-29\"\ncategory: \"payments\"\nauthor: \"BlindPay Team\"\nhowto:\n  name: \"How to integrate and test a virtual accounts API\"\n  steps:\n    - name: \"Create the customer\"\n      text: \"Create an individual or business customer with the API. On a development instance, KYC is auto-approved, and a first or legal name of Fail returns a rejection you can test against.\"\n    - name: \"Fill the compliance fields\"\n      text: \"Before requesting an account, fill the fields the banking partner checks: account purpose, source of wealth, and for businesses the business type, description, NAICS industry code, estimated annual revenue, and owners.\"\n    - name: \"Add the settlement wallet\"\n      text: \"Register the customer's blockchain wallet. Every deposit into the virtual account settles to this wallet. USDT settlement needs a wallet on Polygon, Ethereum, or Solana.\"\n    - name: \"Create the virtual account\"\n      text: \"Call the virtual accounts endpoint with the banking partner, the settlement token, and the blockchain wallet id. Send an Idempotency-Key header so a retried request never creates a second account.\"\n    - name: \"Handle the account webhooks\"\n      text: \"Listen for virtualAccount.new when the account is requested and virtualAccount.complete when the bank approves it and the routing and account numbers are issued.\"\n    - name: \"Handle a payin per deposit\"\n      text: \"Every deposit into the account creates a payin. Handle payin.new, any payin.update, and payin.complete, and treat completed, failed, and refunded as final statuses.\"\n    - name: \"Switch to production\"\n      text: \"Create a production instance and API key, re-create the webhook endpoint, switch USDB to USDC or USDT, submit real KYC documents, and remove any logic that relies on test amounts.\"\nfaq:\n  - q: \"Can I test a virtual accounts API for free?\"\n    a: \"Yes, on BlindPay. A development instance is free and exposes the same endpoints, fields, and webhooks as production. Virtual accounts are approved instantly, deposits are simulated with payins that complete in about 30 seconds, and settlement uses USDB, a test stablecoin. You only pay the $1.50 monthly account fee and deposit fees once real accounts run on a production instance.\"\n  - q: \"How do I simulate a deposit into a virtual account in the sandbox?\"\n    a: \"There is no bank to send from on a development instance, so you simulate the deposit with a payin. Create a payin quote for the customer with ach or wire as the payment method, then create the payin from it within the 5 minute quote window. It completes after about 30 seconds unless you use a test amount that forces a failure or a refund.\"\n  - q: \"Are sandbox virtual account numbers real?\"\n    a: \"No. On a BlindPay development instance the routing number is always 110000000 and the account number is a fake 12-digit number derived from the account id, so it stays the same across requests. No real bank recognizes either value. Never show them to a real payer. Production accounts get bank-issued numbers once the bank approves them.\"\n  - q: \"Why does my production virtual account stay in pending_review?\"\n    a: \"Production accounts go through two reviews. The account sits in pending_review during compliance review, then verifying during bank review, then becomes approved or rejected. Issuance SLAs are 24 hours or 3 to 5 business days depending on account type. If the bank asks for more documents, the SLA clock restarts on the day you submit them.\"\n  - q: \"Can I test a virtual account rejection in the sandbox?\"\n    a: \"Not directly. Development instances approve every virtual account, so a rejected account only happens in production. You can test a rejected customer by setting the first or legal name to Fail. For the account itself, feed your handler a stored payload with a rejected status in a unit test, so the code path exists before the first real rejection arrives.\"\n---\n\nTo test a virtual accounts API integration, run the whole sequence on a development instance: create a customer, fill the compliance fields, link a wallet, create the account, and simulate deposits that complete, fail, and refund. Check every status and webhook along the way. Then plan for what a sandbox can't test: bank review, real payer banks, and name checks.\n\nThe sandbox proves your code. It doesn't prove your approval timeline.\n\n## Key takeaways\n\n- A virtual accounts integration is seven steps, and only one of them is the create call. The rest is compliance fields and webhooks.\n- A sandbox simulates approval and deposits. It can't simulate bank review, the payer's bank, or a beneficiary name check.\n- In production you never create the payins for deposits. Each deposit creates one, so your handler has to accept payins it has never seen.\n- Model one account per customer. Pooled accounts push matching back onto payers, and per-invoice accounts run into review limits and nesting rules.\n\n## What does a virtual accounts API integration involve?\n\nA virtual accounts integration takes a verified customer, gives them their own bank account details, and turns every deposit into a tracked event. The create call is one request. The work around it is customer data, a settlement destination, and webhook handling.\n\nThe sequence at BlindPay looks like this:\n\n1. **Create the customer.** Individual or business. On development, KYC is auto-approved.\n2. **Fill the compliance fields.** Account purpose and source of wealth for everyone. For businesses, also business type, description, NAICS industry code, estimated annual revenue, publicly traded status, and owners with ownership percentage and title.\n3. **Add the settlement wallet.** A blockchain wallet (`bw_...`) the customer controls. Deposits settle there.\n4. **Create the virtual account.** One request with the banking partner, the token, and the wallet id.\n5. **Handle the account webhooks.** `virtualAccount.new` fires when the account is requested, `virtualAccount.complete` when the bank approves it and the numbers are issued.\n6. **Handle one payin per deposit.** `payin.new`, then intermediate `payin.update` events, then `payin.complete`.\n7. **Switch to production.** New instance, new key, new webhook endpoint, real tokens.\n\nStep 2 is where teams lose days. Depending on the banking partner, the API rejects the create request with `missing_required_fields` and names each blank field. Collect those fields in your onboarding form, not in a support thread later. The full list is in [virtual account requirements](\u002Fresources\u002Fmore\u002Fvirtual-account-requirements-kyc-kyb).\n\nIf you're still deciding what a virtual account is for in your product, start with [what is a virtual account](\u002Fresources\u002Fmore\u002Fwhat-is-a-virtual-account).\n\n## What do the create request and response look like?\n\nThe request names the banking partner, the settlement token, and the wallet. The response returns an account id and, once approved, routing and account numbers per rail. Here's an example on a development instance, with placeholder ids:\n\n```bash\ncurl --request POST \\\n  --url https:\u002F\u002Fapi.blindpay.com\u002Fv1\u002Finstances\u002Fin_000000000000\u002Fcustomers\u002Fre_000000000000\u002Fvirtual-accounts \\\n  --header 'Authorization: Bearer YOUR_API_KEY' \\\n  --header 'Content-Type: application\u002Fjson' \\\n  --header 'Idempotency-Key: 6f1c2a9e-onboarding-re_000000000000' \\\n  --data '{\n    \"banking_partner\": \"\u003Celigible_banking_partner>\",\n    \"token\": \"USDB\",\n    \"blockchain_wallet_id\": \"bw_000000000000\"\n  }'\n```\n\nAn abbreviated response, with values a development instance returns:\n\n```json\n{\n  \"id\": \"va_000000000000\",\n  \"kyc_status\": \"approved\",\n  \"token\": \"USDB\",\n  \"blockchain_wallet_id\": \"bw_000000000000\",\n  \"partner_fee_id\": null,\n  \"us\": {\n    \"ach\": { \"routing_number\": \"110000000\", \"account_number\": \"123456789012\" },\n    \"wire\": { \"routing_number\": \"110000000\", \"account_number\": \"123456789012\" }\n  }\n}\n```\n\nThree details matter for your data model. The `token` and `blockchain_wallet_id` can be changed later, but `banking_partner` can't. Before approval, the rail numbers are empty, so don't render payment instructions until they exist. And USDB only works on development: production uses USDC or USDT. The field reference is in [create a virtual account](\u002Fdocs\u002Fvirtual-accounts-create).\n\n## What does a development instance simulate, and what can't it?\n\nA development instance simulates approvals and deposits with the same endpoints, fields, and webhooks as production. It can't simulate anything a real bank does. That gap decides which tests belong in the sandbox and which belong in a controlled production launch.\n\n| Behavior | Development instance | Production instance |\n| --- | --- | --- |\n| Customer KYC | Auto-approved. A first or legal name of `Fail` returns a rejection | Real review: about 60 seconds for KYC Standard, hours to a business day for manual review |\n| Virtual account review | Skipped. Created directly as `approved` | `pending_review`, then `verifying`, then `approved` or `rejected` |\n| Account numbers | Routing `110000000`, fake 12-digit account number that stays the same per account | Real, bank-issued numbers |\n| Deposits | Simulated with a payin that completes in about 30 seconds | Real ACH, wire, or SWIFT transfer, up to 5 business days for ACH and wire |\n| Outcome control | `request_amount` of `66600` fails, `77700` refunds | The real amount is processed |\n| Settlement token | USDB | USDC or USDT |\n| Rate limit | About 100 requests per minute per instance, then `429` | The development cap does not apply |\n\nWhat the sandbox can't tell you: how long bank review takes for your customer mix, whether a payer's bank adds its own delays, whether a sending bank checks the beneficiary name, and which documents the bank asks for. Those are production facts. The general list of what testing misses is in [stablecoin API sandbox vs production](\u002Fresources\u002Fmore\u002Fstablecoin-api-sandbox-vs-production).\n\n## Which test cases should you run?\n\nRun one test per status your product shows and one per webhook your ledger depends on. The table below covers the virtual account cases. Simulate each deposit with a payin quote for the customer using `ach` or `wire`, then a payin created from it within the 5 minute quote window.\n\n| Test | How to trigger it | Expected result |\n| --- | --- | --- |\n| Customer rejected | Create a customer with first or legal name `Fail` | Customer `rejected`. Your onboarding should block account creation |\n| Missing compliance fields | Request an account for a business with `account_purpose` blank | `missing_required_fields` naming each blank field, depending on the banking partner |\n| Account created | Valid create request | `approved` right away, `virtualAccount.new` fires |\n| Retried create | Resend the same request with the same `Idempotency-Key` and identical body | Original response replayed with `Idempotency-Replayed: true`, no second account |\n| Second account | Request another account for the same customer on the same banking partner | Rejected, except on the one partner that allows several accounts per customer |\n| Deposit completes | Payin with any normal amount | `payin.new`, then `payin.complete` with status `completed`; `blindpay_bank_details` shows the account's own numbers |\n| Deposit fails | `request_amount` of `66600` ($666.00) | Status `failed` |\n| Deposit refunds | `request_amount` of `77700` ($777.00) | Status `refunded` |\n| Fee fields | Any completed deposit | Your ledger stores both `billing_fee_amount` and `transaction_fee_amount` without assuming either is set. Development is free, so check real values on the first production deposits |\n| Duplicate webhook | Replay an event from the webhook dashboard | Your handler deduplicates on `svix-id` and changes nothing |\n\nTwo of these catch most production bugs. The retried create, because a timeout during onboarding is common and a second account is a support ticket. And the duplicate webhook, because replays happen. Signature checks and dedupe patterns are in [stablecoin API webhooks](\u002Fresources\u002Fmore\u002Fstablecoin-api-webhooks-reconciliation), and key handling is in [idempotency keys](\u002Fresources\u002Fmore\u002Fstablecoin-api-idempotency-keys).\n\nOne production difference changes how you write the deposit handler. In the sandbox you create the payin yourself. In production, BlindPay creates a payin for every deposit that lands on the account and sends `payin.new`. Match it on `customer_id` and the account number in `blindpay_bank_details`, never on a payin id you stored earlier.\n\n## Should you create one account per customer, per invoice, or a pooled account?\n\nCreate one account per customer. That's the model virtual accounts are built for: the receiving account number identifies who paid, and the account is reviewed once. Pooled accounts and per-invoice accounts both work in narrow cases, with real costs.\n\n| | Single pooled account | One account per customer | One account per invoice |\n| --- | --- | --- | --- |\n| What the payer sees | A shared account plus a reference or memo code | The customer's own routing and account number | A new account number on every invoice |\n| How deposits are matched | The payer types the reference correctly | By the receiving account number | By account number, at invoice level |\n| Review | None per payment | Once per customer | Once per account, so once per invoice |\n| At BlindPay | Payin quote without a virtual account: `ach` and `wire` use a memo code, capped at $500,000 per transaction, and SWIFT isn't available | The default model, with SWIFT available once approved | Limited: a customer holds one account per banking partner, with one partner allowing several |\n| Main risk | Payers drop the reference and someone matches by hand | Approval time before the first deposit | Review per account, payers reusing old details, and nesting |\n\nNesting is the reason per-invoice designs fail review. If each account really represents a different client of your customer, the money belongs to parties the provider never verified. BlindPay's rule is in [nested payments](\u002Fdocs\u002Fkb\u002Fnested-payments). For invoice-level matching on one account, use amounts and the payment records instead; [how virtual accounts automate reconciliation](\u002Fresources\u002Fmore\u002Fvirtual-account-reconciliation) walks through partial payments and overpayments.\n\n## What does a test plan look like for a payroll platform?\n\n*Illustrative example, not a real customer.* A payroll platform lets employers fund payroll by sending ACH or wire to their own virtual account, which settles to USDC before payouts go to contractors. The team writes a sandbox plan with three test employers.\n\n**Employer A, the happy path.** A US business with every compliance field filled.\n\n1. `customer.new`, then `blockchainWallet.new` when the wallet is added.\n2. Create the account: `approved` in the response, `virtualAccount.new` fires.\n3. Simulate a $12,000.00 funding deposit: `payin.new`, then `payin.complete` about 30 seconds later, status `completed`.\n4. Confirm the ledger stores both fee fields from the payin, even though development charges no fees. In production, the fee lands in `billing_fee_amount` below $100.00 and in `transaction_fee_amount` at $100.00 or more.\n\n**Employer B, the bad deposits.** Same setup, then two payins: `66600` ends `failed` and `77700` ends `refunded`. The team checks that the payroll run stays blocked in both cases and that the employer sees a clear \"funding returned\" state instead of a spinner.\n\n**Employer C, the rejected customer.** Legal name `Fail`. KYC comes back `rejected`, and the onboarding screen stops before the account request. No `virtualAccount.new` should ever fire for this employer.\n\nThe plan takes an afternoon. What it doesn't cover goes into a launch checklist: the first real employer's review time, the first real ACH arrival time, and the first micro-deposit (a $0.01 test some payroll providers send), which shows up as a real payin and should be reconciled, not flagged.\n\n## What changes when you switch to production?\n\nEverything that touches a bank becomes real, and the approval step comes back. Plan for both before you migrate the first customer.\n\n- **New instance and key.** Production instances are created in the dashboard and can take up to 3 business days to provision. Development keys don't work on them.\n- **Re-create webhooks.** The development webhook endpoint doesn't carry over.\n- **Real tokens.** Switch USDB to USDC or USDT. USDT needs a wallet on Polygon, Ethereum, or Solana.\n- **Real review.** Accounts go through compliance and bank review, with SLAs of 24 hours or 3 to 5 business days by account type. If the bank asks for more documents, the clock restarts when you submit them.\n- **Remove test amounts.** On production, $666.00 and $777.00 are just amounts.\n- **Real fees.** $1.50 per month per account, plus the fee on each deposit's payin.\n\nBuild the onboarding screen around the review time, not the API response time. That's the one thing the sandbox hides.\n\n## Where does BlindPay fit?\n\nBlindPay issues US virtual accounts in your customer's name that receive ACH, wire, and SWIFT (POBO\u002FCOBO) transfers and settle to USDC or USDT in a wallet the customer controls. The free development instance uses the same base URL as production, `https:\u002F\u002Fapi.blindpay.com`, and which environment you hit depends on the instance your API key belongs to.\n\nFor the build itself, there's a public OpenAPI 3.1 spec, official SDKs for Node.js, Python, Go, PHP, and Swift ([SDKs](\u002Fdocs\u002Fsdks)), and a [CLI](\u002Fblog\u002Fcli) where `blindpay virtual_accounts create` runs the same request from a terminal. For the full evaluation beyond testing, see [how to choose a virtual account provider](\u002Fresources\u002Fmore\u002Fhow-to-choose-a-virtual-account-provider), and for what the payer side costs, [virtual account fees](\u002Fresources\u002Fmore\u002Fvirtual-account-fees).\n\nWhat BlindPay doesn't do: issue virtual IBANs, or accounts outside the US. Deposits that never show up are covered in [virtual account deposit not received](\u002Fresources\u002Fmore\u002Fvirtual-account-deposit-not-received).\n\n## What to do next\n\nCreate a free development instance, then run the ten test cases in the table above against your own webhook endpoint, starting with the retried create and the duplicate webhook. The request reference is in [create a virtual account](\u002Fdocs\u002Fvirtual-accounts-create), and the full sandbox behavior is in [sandbox vs production](\u002Fdocs\u002Flearn\u002Fsandbox-vs-production).\n\n*This article is for general information only and is not legal, tax, or financial advice.*\n",{"title":5,"description":1128},"Virtual accounts API: how to test it in a sandbox","resources\u002Fmore\u002Fhow-to-test-virtual-accounts-sandbox","DGPCTUBLJH6vFps9oR5cBMXte4pqmWYBf_sOEbBWctM",[1181,1185,1189,1193,1197,1201,1205,1209,1213,1217,1221,1225,1229,1233,1237,1241,1245,1249,1253,1257,1260,1264,1268,1272,1276,1280,1284,1288,1292,1296,1297,1300,1303,1307,1311,1315,1319,1323,1327,1331,1335,1339,1342,1345,1349,1353,1357,1361,1365,1369,1373,1377,1381,1385,1389,1393,1397,1401,1405,1409,1412,1416,1420,1424,1428,1432,1436,1440,1443,1447,1451,1455,1459],{"path":1182,"title":1183,"description":1184},"\u002Fresources\u002Fmore\u002Fagent-payment-protocols-compared","AP2 vs ACP vs x402: agent payment protocols compared","AP2, ACP, and x402 each verify that an AI agent had permission to spend. Here is what every protocol covers, who backs it, and the reconciliation gap none of them close.",{"path":1186,"title":1187,"description":1188},"\u002Fresources\u002Fmore\u002Fbest-stablecoin-payment-platform-fintech-2026","Best stablecoin payment platforms for fintech in 2026: a US comparison","Seven stablecoin payment platforms compared for US fintechs in 2026: what makes an API production-ready, how each provider handles compliance, settlement speed against ACH, and how to run the evaluation.",{"path":1190,"title":1191,"description":1192},"\u002Fresources\u002Fmore\u002Fbest-stablecoin-payment-providers-2026","Best stablecoin payment providers in 2026: how to choose","How to choose a stablecoin payment provider in 2026: the four provider types, a comparison of 10 options, and the questions that decide the fit.",{"path":1194,"title":1195,"description":1196},"\u002Fresources\u002Fmore\u002Fwhat-are-blockchain-payments","Blockchain payments explained: how stablecoins move money without correspondent banks","Blockchain payments move a stablecoin on a public ledger instead of messages between banks. How they work, what they cost, and how they compare with SWIFT.",{"path":1198,"title":1199,"description":1200},"\u002Fresources\u002Fmore\u002Fbuild-vs-buy-stablecoin-payments","Build vs buy: should you build stablecoin payouts in-house or use an API?","Building stablecoin payouts in-house means wallets, liquidity, banking partners, licenses, and a compliance program. When building makes sense.",{"path":1202,"title":1203,"description":1204},"\u002Fresources\u002Fmore\u002Fcan-a-virtual-account-replace-a-bank-account","Can a virtual account replace a business bank account? What each one does for cross-border companies","Usually not. A virtual account collects and settles payments; a bank account runs payroll, taxes, and credit. A job-by-job guide for cross-border teams.",{"path":1206,"title":1207,"description":1208},"\u002Fresources\u002Fmore\u002Flatam-payout-liquidity-partner-pix-spei","Choosing a liquidity partner for LatAm payouts: Pix, SPEI, and beyond","How to choose a liquidity partner for payouts into Latin America: how Pix and SPEI work, how a stablecoin liquidity layer replaces local bank accounts, and a checklist for coverage, pricing, and compliance.",{"path":1210,"title":1211,"description":1212},"\u002Fresources\u002Fmore\u002Fstablecoin-payout-mistakes","Common stablecoin payout mistakes: wrong network, expired quotes, and bad bank details","The mistakes that make stablecoin payouts fail or stall: wrong network or token, expired quotes, deposits below minimums, bad bank details, and cut-offs.",{"path":1214,"title":1215,"description":1216},"\u002Fresources\u002Fmore\u002Fcorrespondent-banking-vs-stablecoin-liquidity","Correspondent banking vs stablecoin liquidity: why pre-funding traps your capital","Correspondent banking keeps cross-border payouts liquid by parking cash in nostro accounts in every country. What that trapped capital costs a treasury team, and what stablecoin liquidity changes.",{"path":1218,"title":1219,"description":1220},"\u002Fresources\u002Fmore\u002Fcrypto-payment-processor-for-businesses","Crypto payment processor for businesses: what to compare before you choose","Compare crypto payment processors on six criteria: settlement speed, stablecoins, compliance, dev effort, payout coverage, and pricing. Scorecard inside.",{"path":1222,"title":1223,"description":1224},"\u002Fresources\u002Fmore\u002Fcustodial-vs-non-custodial-off-ramps","Custodial vs non-custodial off-ramps: who holds the money, and what happens if the provider fails","A custodial off-ramp holds your stablecoins; a non-custodial one pulls them only at payout. What changes in insolvency, de-banking, and failed payouts.",{"path":1226,"title":1227,"description":1228},"\u002Fresources\u002Fmore\u002Fcustodial-vs-non-custodial-vs-mpc-wallets","Custodial vs non-custodial vs MPC wallets: how to choose","Custodial, non-custodial, and MPC wallets differ in who holds the keys. Compare control, recovery, risk, and regulation, with product examples for each.",{"path":1230,"title":1231,"description":1232},"\u002Fresources\u002Fmore\u002Fstablecoin-cross-border-payments-savings","How businesses use stablecoins for cross-border payments (and where the savings come from)","Correspondent hops, FX markup, and pre-funding: what stablecoin settlement does to each cost of a cross-border payment, with a $50,000 example to Brazil.",{"path":1234,"title":1235,"description":1236},"\u002Fresources\u002Fmore\u002Fhow-a-stablecoin-payment-works","How does a stablecoin payment move? From bank deposit to local payout, step by step","A stablecoin payment moves in legs: fiat collected, stablecoin settled, fiat paid out. What happens at each step, where delays hide, what recipients see.",{"path":1238,"title":1239,"description":1240},"\u002Fresources\u002Fmore\u002Fcross-border-merchant-payments-without-pre-funding","How global merchants get paid across borders with stablecoins, no pre-funding required","Pre-funding means parking local currency in every market before money moves. Stablecoin virtual accounts remove it. A worked example across 4 countries.",{"path":1242,"title":1243,"description":1244},"\u002Fresources\u002Fmore\u002Fstablecoin-payout-settlement-times","How long does a stablecoin payout take? Settlement times by country and rail","Stablecoin payouts settle in minutes on Pix, SPEI, RTP, and Transfers 3.0, and in 1 to 5 business days on ACH, SEPA, and SWIFT. Full table by rail.",{"path":1246,"title":1247,"description":1248},"\u002Fresources\u002Fmore\u002Fcrypto-on-ramp-fees-explained","How much does a crypto on-ramp cost? Fees, spreads, and how to read a quote","A crypto on-ramp charges through the rate spread, a service fee, the payment rail, and sometimes the network. How each works, and how to read the quote.",{"path":1250,"title":1251,"description":1252},"\u002Fresources\u002Fmore\u002Fstablecoin-off-ramp-fees-explained","How much does a stablecoin off-ramp cost? Fees per transaction vs a bank wire","What a stablecoin off-ramp costs per transaction: network fee, FX spread, percentage and flat fees, worked at $200, $2,000, and $20,000 vs a bank wire.",{"path":1254,"title":1255,"description":1256},"\u002Fresources\u002Fmore\u002Fhow-to-add-stablecoin-payments-to-your-wallet-integration","How to add stablecoin payments to your wallet integration","Connect the wallets you already run to bank deposits and local payouts: register addresses, open virtual accounts, quote, authorize, and track webhooks.",{"path":1077,"title":1258,"description":1259},"How to choose a virtual account provider: a 12-point checklist for developers and finance teams","Twelve criteria for evaluating a virtual account API, from rails and naming to custody, webhooks, and pricing, plus red flags and a scorecard to copy.",{"path":1261,"title":1262,"description":1263},"\u002Fresources\u002Fmore\u002Fhow-to-choose-on-off-ramp-provider","How to choose the best on\u002Foff ramp provider for your fintech app","Six criteria for evaluating a crypto on\u002Foff ramp provider: corridor coverage, live quotes, fiat settlement speed, licensing, API quality, and liquidity depth. Each with concrete tests to run, a comparison table, and a scoring framework.",{"path":1265,"title":1266,"description":1267},"\u002Fresources\u002Fmore\u002Fhow-to-evaluate-payment-orchestration-platform","How to evaluate a payment orchestration platform for cross-border payments","Six criteria that decide whether an orchestration platform works for cross-border money: rail coverage, compliance per corridor, developer experience, settlement speed, FX transparency, and pricing.",{"path":1269,"title":1270,"description":1271},"\u002Fresources\u002Fmore\u002Fhow-to-integrate-a-crypto-on-ramp-api","How to integrate a crypto on-ramp API: payin quotes, deposit instructions, and webhooks","The on-ramp API flow step by step: verify the customer, pick the wallet, quote, create the payin, show deposit instructions, and handle webhooks.",{"path":1273,"title":1274,"description":1275},"\u002Fresources\u002Fmore\u002Fhow-to-issue-stablecoin-cards-api","How to issue stablecoin-funded cards through an API: a developer's guide","Build vs. buy for stablecoin card issuing, the objects a card issuing API must expose, a step-by-step integration flow, and where KYC and KYB sit in it.",{"path":1277,"title":1278,"description":1279},"\u002Fresources\u002Fmore\u002Fhow-to-off-ramp-usdc-to-us-bank-account","How to off-ramp USDC to a US bank account: ACH, RTP, or wire","Cashing out USDC or USDT to a US bank account: when ACH, Same Day ACH, RTP, and wire pay out, the cut-offs in ET, the fields you need, and what delays it.",{"path":1281,"title":1282,"description":1283},"\u002Fresources\u002Fmore\u002Fhow-to-off-ramp-usdc-to-euros-sepa","How to off-ramp USDC to euros over SEPA: networks, IBAN details, and timing","Converting USDC to EUR in a SEPA bank account: which networks work, the IBAN details you need, SEPA vs SEPA Instant timing, limits, and what MiCA changes.",{"path":1285,"title":1286,"description":1287},"\u002Fresources\u002Fmore\u002Fhow-to-off-ramp-usdt-latin-america","How to off-ramp USDT to local currency in Latin America","Converting USDT to BRL, MXN, ARS, or COP: which networks work, the payout rail in each country, weekend timing, fees, and the documents a business needs.",{"path":1289,"title":1290,"description":1291},"\u002Fresources\u002Fmore\u002Fhow-to-on-ramp-local-currency-latin-america","How to on-ramp BRL, MXN, ARS, and COP into stablecoins: Pix, SPEI, Transfers 3.0, and PSE","How Latin American bank payments become USDC or USDT: what each rail shows the payer, the payer data it needs, how fast it lands, and the traps by country.",{"path":1293,"title":1294,"description":1295},"\u002Fresources\u002Fmore\u002Fhow-to-send-usdc-to-bank-account-brazil","How to send USDC to a bank account in Brazil","Step-by-step: convert USDC to Brazilian reais and deliver them to a bank account over Pix using a stablecoin payout API. Quote, verify, send, settle in minutes.",{"path":1174,"title":5,"description":1128},{"path":906,"title":1298,"description":1299},"How virtual accounts automate payment reconciliation (with a worked example)","Virtual accounts match each deposit to a customer by account number, not a free-text reference. A worked example with partial payments and micro-deposits.",{"path":780,"title":1301,"description":1302},"Idempotency keys in a stablecoin API: how to never send the same payout twice","A timeout on a payout call is the most common way to pay someone twice. How idempotency keys prevent it, what replays, what conflicts, and how to retry.",{"path":1304,"title":1305,"description":1306},"\u002Fresources\u002Fmore\u002Fhow-to-integrate-a-stablecoin-api","Integrating a stablecoin API: a developer's guide to cross-border payments with BlindPay","Step-by-step integration of a stablecoin API: authenticate, onboard a customer, create a virtual USD account, quote and send a cross-border payout, and handle signed webhooks. Endpoints, statuses, and SDKs for BlindPay.",{"path":1308,"title":1309,"description":1310},"\u002Fresources\u002Fmore\u002Fliquidity-risk-global-payouts","Managing liquidity risk in global payouts: a practical guide for fintechs and PSPs","Liquidity risk in payouts is the chance funds aren't available at the right rate, in the right currency, when a payout settles. Its four sources and a six-step framework to manage them.",{"path":1312,"title":1313,"description":1314},"\u002Fresources\u002Fmore\u002Fmarketplace-stablecoin-payouts-latam","Marketplace payouts in Latin America: stablecoin rails for sellers in Brazil, Mexico, Colombia, and Argentina","How marketplaces pay sellers, creators, and vendors across Latin America with stablecoin settlement: supported rails (Pix, SPEI, PSE, Argentine transfers), the end-to-end payout workflow, API integration, and what changes for speed, minimums, and FX cost.",{"path":1316,"title":1317,"description":1318},"\u002Fresources\u002Fmore\u002Fnon-custodial-payments-explained","Non-custodial payments: what they are and why they reduce risk for businesses","A non-custodial payment provider moves your money without holding it between payments. Who controls the funds, who carries the risk, and what to ask.",{"path":1320,"title":1321,"description":1322},"\u002Fresources\u002Fmore\u002Fon-off-ramp-liquidity-live-quotes","On\u002Foff ramp liquidity with live quotes: how it works and why it matters","What on\u002Foff ramp liquidity with live quotes means for developers: live quote vs batch rate, the quote ID flow in an API, what happens on expiry, how liquidity depth changes spread by transaction size, rate windows and UX, and a checklist for evaluating a live quote API.",{"path":1324,"title":1325,"description":1326},"\u002Fresources\u002Fmore\u002Fpayment-orchestration-vs-payment-gateway","Payment orchestration vs payment gateway: what's the difference?","A gateway connects you to one processor. An orchestration platform connects to many rails and picks the best path per transaction. The table, the triggers, and a worked USD to BRL example.",{"path":1328,"title":1329,"description":1330},"\u002Fresources\u002Fmore\u002Fstablecoin-api-openapi-sdks","Stablecoin API SDKs: how one OpenAPI spec keeps five languages in sync","BlindPay's stablecoin API is described by one OpenAPI 3.1 spec that drives validation, docs, SDKs for Node, Python, Go, PHP, and Swift, and the MCP server.",{"path":1332,"title":1333,"description":1334},"\u002Fresources\u002Fmore\u002Fstablecoin-api-sla-settlement-finality","Stablecoin API SLAs and settlement finality explained","Stablecoin API uptime numbers cluster near 99.9% for a reason: most providers measure API acceptance instead of the point where money becomes final and spendable.",{"path":1336,"title":1337,"description":1338},"\u002Fresources\u002Fmore\u002Fstablecoin-api-quotes-explained","Stablecoin API quotes explained: expiry, fee direction, and minor units","A stablecoin API quote locks the rate, fees, and amounts for a few minutes. How expiry works, which side pays the fee, and the field that flips meaning.",{"path":567,"title":1340,"description":1341},"Stablecoin API sandbox vs production: what testing misses","Most stablecoin API sandboxes pass every integration test and still leave a team unprepared for production, because webhook delivery and idempotent retries are exactly what sandboxes fake or skip.",{"path":775,"title":1343,"description":1344},"Stablecoin API webhooks: signature checks, duplicate events, and reconciliation","How to handle stablecoin API webhooks in production: verify signatures on raw bytes, dedupe retries, never regress a final status, reconcile daily.",{"path":1346,"title":1347,"description":1348},"\u002Fresources\u002Fmore\u002Fstablecoin-fx-slippage-live-quotes","Stablecoin FX slippage: how live quotes turn the quoted rate into the rate you get","FX slippage is the gap between the rate a stablecoin on-ramp or off-ramp shows and the rate that settles. Why quote freshness is a liquidity signal, and how to check a quote-then-execute flow.",{"path":1350,"title":1351,"description":1352},"\u002Fresources\u002Fmore\u002Fstablecoin-cards-latin-america","Stablecoin cards in Latin America: how they work in Brazil, Mexico, Argentina, and Colombia","How USD stablecoin cards work in Brazil, Mexico, Argentina, and Colombia: local card and crypto rules, costs at the point of sale, and when a Pix or SPEI payout fits better.",{"path":1354,"title":1355,"description":1356},"\u002Fresources\u002Fmore\u002Fstablecoin-liquidity-provider-vs-fx-desk","Stablecoin liquidity providers vs traditional FX desks: what finance teams should know","A bank FX desk prices cross-border payouts by relationship. A stablecoin liquidity provider prices them by API. How the two compare on cost, speed, minimums, coverage, and compliance.",{"path":1358,"title":1359,"description":1360},"\u002Fresources\u002Fmore\u002Fstablecoin-payment-fees-vs-card-processing-fees","Stablecoin payment fees vs credit card processing fees: what merchants actually pay","Cards cost merchants 1.5% to 3.5% plus cross-border, FX, and chargeback fees. Stablecoin payments cost cents on-chain plus a sub-percent conversion spread.",{"path":1362,"title":1363,"description":1364},"\u002Fresources\u002Fmore\u002Fstablecoin-payments-guide","Stablecoin payments explained: a guide for businesses","Stablecoin payments move dollar-pegged tokens between parties and settle in minutes, 24\u002F7. How they work, what they cost, and how businesses accept and send them.",{"path":1366,"title":1367,"description":1368},"\u002Fresources\u002Fmore\u002Fstablecoin-payout-statuses-explained","Stablecoin payout statuses explained: processing, on hold, completed, failed, and refunded","What each stablecoin payout status means, which are final, why an on-chain confirmation isn't a completed payout, and how to test every failure.",{"path":1370,"title":1371,"description":1372},"\u002Fresources\u002Fmore\u002Fstablecoin-payroll-latam-contractors","Stablecoin payroll for LATAM contractors: how it actually works in 2026","How US companies pay contractors in Argentina, Brazil, Mexico, and Colombia with stablecoins in 2026: USDC vs USDT, the step-by-step payout flow, US tax reporting, a platform comparison, and how to start.",{"path":1374,"title":1375,"description":1376},"\u002Fresources\u002Fmore\u002Fstablecoin-settlement-for-merchants","Stablecoin settlement explained: how merchants get paid faster than card networks","Stablecoin payments settle in seconds to minutes, final and 24\u002F7. Cards take 1 to 3 business days and wires up to 5. How it works and how to cash out.",{"path":1378,"title":1379,"description":1380},"\u002Fresources\u002Fmore\u002Fstablecoin-virtual-accounts-explained","Stablecoin virtual accounts explained: from bank transfer to wallet balance","A stablecoin virtual account is a bank account in your customer's name whose deposits convert to USDC or USDT. How approval, deposits, and fees work.",{"path":1382,"title":1383,"description":1384},"\u002Fresources\u002Fmore\u002Fstablecoin-virtual-cards-cross-border-payouts","Stablecoin-funded virtual cards vs. traditional virtual cards for cross-border payouts","Stablecoin-funded vs. bank-funded virtual cards for paying contractors and vendors abroad: funding speed, pre-funding, FX cost, settlement finality, and a Brazil walkthrough.",{"path":1386,"title":1387,"description":1388},"\u002Fresources\u002Fmore\u002Fstablecoins-local-rails-latin-america","Stablecoins plus local rails: how cross-border payments actually land in Latin America","A stablecoin crosses the border in seconds, but the payment lands over Pix, SPEI, or another local rail. How that last mile works in Brazil and Mexico.",{"path":1390,"title":1391,"description":1392},"\u002Fresources\u002Fmore\u002Fstablecoin-vs-swift-b2b-payments","Stablecoins vs SWIFT for B2B cross-border payments: a real comparison","Where SWIFT wires still win, where stablecoin settlement wins, and how to compare the two on cost, speed, traceability, and failure modes for business payments in 2026.",{"path":1394,"title":1395,"description":1396},"\u002Fresources\u002Fmore\u002Fusdc-to-ars-routes-2026","USDC to ARS in 2026: routes, fees, and rules compared","Four ways to convert USDC to Argentine pesos in 2026: stablecoin payout APIs, local exchanges, P2P, and global exchanges with Transfers 3.0. Fees, speed, KYC, and Argentina's PSAV rules compared.",{"path":1398,"title":1399,"description":1400},"\u002Fresources\u002Fmore\u002Fusdc-to-brl-routes-2026","USDC to BRL in 2026: routes, fees, and rules compared","Four ways to convert USDC to Brazilian reais in 2026: stablecoin payout APIs, local exchanges, P2P, and global exchanges with Pix. Fees, speed, KYC, and Brazil's VASP rules compared.",{"path":1402,"title":1403,"description":1404},"\u002Fresources\u002Fmore\u002Fusdc-to-cop-routes-2026","USDC to COP in 2026: routes, fees, and rules compared","Four ways to convert USDC to Colombian pesos in 2026: stablecoin payout APIs, local exchanges, P2P, and global exchanges with PSE. Fees, speed, KYC, and Colombia's VASP rules compared.",{"path":1406,"title":1407,"description":1408},"\u002Fresources\u002Fmore\u002Fusdc-to-mxn-routes-2026","USDC to MXN in 2026: routes, fees, and rules compared","Four ways to convert USDC to Mexican pesos in 2026: stablecoin payout APIs, local exchanges, P2P, and global exchanges with SPEI. Fees, speed, KYC, and Mexico's rules compared.",{"path":1089,"title":1410,"description":1411},"Virtual account deposit not received? Why deposits get delayed, held, or returned","Why a virtual account deposit is late, on hold, or returned: arrival windows, payin statuses, RFIs, wrong rails, and how to trace a wire or SWIFT payment.",{"path":1413,"title":1414,"description":1415},"\u002Fresources\u002Fmore\u002Fvirtual-account-vs-virtual-iban","Virtual account vs virtual IBAN vs real bank account: what's the difference?","A real account holds funds for one holder. A virtual account routes deposits into a master account. A virtual IBAN is the IBAN version. When to use each.",{"path":1417,"title":1418,"description":1419},"\u002Fresources\u002Fmore\u002Fvirtual-accounts-cross-border-payments","Virtual accounts for cross-border payments: use cases, payment rails, and costs","How virtual accounts let payers abroad pay a local-style account, which rails collect and pay out, what drives the cost, and five questions to ask.",{"path":1421,"title":1422,"description":1423},"\u002Fresources\u002Fmore\u002Fpix-key-cpf-clabe-payout-details","What details do you need to pay someone in Brazil or Mexico? Pix keys, CPF, and CLABE","What a payout to Brazil or Mexico needs from the recipient: Pix key types, CPF and CNPJ formats, the 18-digit CLABE, and the checks that stop a bad payout.",{"path":1425,"title":1426,"description":1427},"\u002Fresources\u002Fmore\u002Fno-pre-funding-stablecoin-payouts","What does \"no pre-funding\" mean in a stablecoin API?","No pre-funding means each payout is funded when you send it, not from a balance parked in advance. The three funding models, the math, and what to ask.",{"path":1429,"title":1430,"description":1431},"\u002Fresources\u002Fmore\u002Fwhat-is-a-crypto-on-ramp-and-off-ramp","What is a crypto on-ramp and off-ramp? A guide for fintech builders","A crypto on-ramp converts fiat into stablecoins or crypto; an off-ramp converts them back into fiat in a bank account. How each works step by step, how they differ, which payment methods on-ramps support, and who they are built for.",{"path":1433,"title":1434,"description":1435},"\u002Fresources\u002Fmore\u002Fwhat-is-a-liquidity-market-cross-border-payments","What is a liquidity market in cross-border payments? And why stablecoin liquidity is changing it","A liquidity market in cross-border payments is where the currency to settle a transfer gets sourced. How correspondent banks pre-fund it, and how stablecoin liquidity changes the model.",{"path":1437,"title":1438,"description":1439},"\u002Fresources\u002Fmore\u002Fwhat-is-a-stablecoin-offramp","What is a stablecoin off-ramp? How crypto becomes cash","A stablecoin off-ramp converts stablecoins like USDC or USDT back into fiat currency in a bank account. How the conversion works and who regulates it.",{"path":135,"title":1441,"description":1442},"What is a virtual account? A plain-English guide for fintech teams","A virtual account is a unique set of bank details that routes incoming payments to one customer or purpose. How it works, who uses it, and where it fits.",{"path":1444,"title":1445,"description":1446},"\u002Fresources\u002Fmore\u002Fwhat-is-payment-orchestration","What is payment orchestration? The routing layer, explained","Payment orchestration is the routing layer between your app and every processor, bank, and rail you use. The five layers, how stablecoin settlement fits, and how it differs from a gateway.",{"path":1448,"title":1449,"description":1450},"\u002Fresources\u002Fmore\u002Fstablecoin-payments-provider-due-diligence","What to ask a stablecoin payments provider: 30 due diligence questions","The questions to ask a stablecoin payments vendor before you sign: licensing, custody, pricing, rails, compliance, failure handling, security, and exit.",{"path":1452,"title":1453,"description":1454},"\u002Fresources\u002Fmore\u002Fhow-to-track-a-crypto-off-ramp-payout","Where is my off-ramp payout? How to track it rail by rail, and what to tell the recipient","Track an off-ramp payout from transaction hash to bank: the reference each rail gives you (Pix E2E ID, SPEI key, ACH trace, UETR) and status copy.",{"path":1456,"title":1457,"description":1458},"\u002Fresources\u002Fmore\u002Fwhy-are-cross-border-payments-slow","Why are cross-border payments slow? Where the days go in an international wire","Most SWIFT payments reach the destination bank within an hour. The days go to cut-offs, correspondent hops, compliance checks, and local crediting.",{"path":1460,"title":1461,"description":1462},"\u002Fresources\u002Fmore\u002Fwhy-crypto-on-ramp-deposits-fail","Why crypto on-ramp deposits fail: missing references, late transfers, holds, and refunds","Most failed on-ramps fail on the fiat side: a missing reference, the wrong payer, a late transfer, a hold. What happens to the money in each case.",1790867705086]