> For the complete documentation index, see [llms.txt](https://developers.bead.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developers.bead.xyz/reference-guide/payment-scenarios/refunds-for-crypto-and-wallet-payments.md). # Refunds for Crypto and Wallet Payments Crypto, digital wallet, and BNPL payments through Bead settle like cash. When a customer completes a payment using one of these tenders, the transaction closes at the point of sale. The funds are converted, settled, and deposited into the merchant's bank account as USD. There is no underlying card network, no issuing bank, and no chargeback rail. As a result, there is no API-level refund capability for completed transactions. This page explains why, and what merchants and integrators should do instead. This page covers post-completion return scenarios only. If you are looking for guidance on payments that did not complete successfully, see [Under- and Over-Payment Handling](/reference-guide/payment-scenarios/under-and-over-payment-handling.md) and [Reclaiming Unconverted Crypto](/reference-guide/payment-scenarios/reclaiming-unconverted-crypto.md). #### How these payments settle When a customer pays with crypto, a digital wallet, or BNPL through Bead, the following happens: 1. The customer's payment is received and confirmed on the relevant network or rail. 2. For crypto, the digital asset is converted to USD at the time of payment. The original asset is no longer held. 3. The USD value, net of fees, is settled to the merchant's bank account via ACH, typically on the next business day. By the time a merchant wants to issue a refund, the original payment has already been converted and deposited. There is no crypto balance, wallet balance, or BNPL transaction to reverse. The funds are in the merchant's bank account as USD. #### Why there is no refund API **The asset no longer exists in returnable form** Once a crypto payment is converted to USD and settled, the specific digital assets the customer sent are gone. Sending crypto back to a customer would require sourcing new assets, which is structurally a new outbound transfer, not a reversal of the original transaction. **Outbound crypto transfers carry regulatory requirements** Under the Bank Secrecy Act and FinCEN's Funds Travel Rule, outbound transfers of digital assets above regulatory thresholds require identity verification, sanctions screening, and in some cases Suspicious Activity Report filing. Enabling an API-level refund for crypto would require building a compliant outbound crypto transfer system with meaningful regulatory overhead, not a simple reversal endpoint. This is also why Bead's reclaim process for failed or exception payments exists as a separate controlled flow. It handles the narrow case of returning funds that were never successfully settled, and does so with the appropriate compliance controls in place. **Crypto in and crypto out creates financial crime risk** Allowing a merchant to receive a crypto payment, convert it to USD, and then trigger a crypto payout back to a customer creates a structure that regulators recognize as a potential money laundering or asset conversion vehicle. Bead operates as a software and agent layer, not a money transmitter or exchange. Enabling this flow would expose Bead and its sponsor bank to Money Services Business and Money Transmitter regulatory risk. **The same applies to digital wallets and BNPL** Digital wallet payments such as PayPal and Venmo and BNPL payments such as Klarna settle to the merchant as USD through Bead's settlement infrastructure. There is no open wallet session or BNPL loan record that Bead can reverse after settlement. Those rails do not expose a merchant-initiated reversal capability to Bead at the point-of-sale integration layer. #### What merchants should do Because these tenders settle like cash, merchants should apply their standard cash return policy to any customer requesting a refund on a Bead-tendered transaction. That policy may include any of the following: * Cash back from the register or till * ACH or check issued from the merchant's bank account * Store credit, gift card, or credit memo issued in the merchant's own system * Exchange for another item or service The appropriate refund method is determined entirely by the merchant's return policy, not by the payment method used at the time of purchase. Merchants should communicate their return policy clearly to customers at the time of purchase, particularly for high-value transactions, to avoid friction at the point of return. #### What integrators should know There is no refund endpoint. Do not build against one. The `fullyRefunded` and `partiallyRefunded` payment status codes are reserved for future use and are not currently returned by the API. The reclaim process handles a separate scenario: returning unconverted funds to a customer when a payment fails due to underpayment, overpayment, expiration, or cancellation. This is not a merchant-initiated refund. It is an exception flow managed by Bead for payments that never successfully completed. See [Reclaiming Unconverted Crypto](/reference-guide/payment-scenarios/reclaiming-unconverted-crypto.md) for details on that flow. For reporting and reconciliation, use the Reporting and Settlement APIs to identify completed transactions. Refund events handled outside of Bead through cash, ACH, or store credit should be tracked in your own order management or point-of-sale system. #### Related pages * [Under- and Over-Payment Handling](/reference-guide/payment-scenarios/under-and-over-payment-handling.md) * [Reclaiming Unconverted Crypto](/reference-guide/payment-scenarios/reclaiming-unconverted-crypto.md) * [Payment Statuses](/payments/payment-statuses.md) * [Receipts](/payments/receipts.md) * [Reporting](/reporting.md) * [Settlement](/settlement.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://developers.bead.xyz/reference-guide/payment-scenarios/refunds-for-crypto-and-wallet-payments.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.