> 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/faqs-and-troubleshooting/payments-faqs/consumer-fee-passthrough-for-wallet-and-crypto-tenders.md). # Consumer Fee Passthrough for Wallet and Crypto Tenders This page provides directional information about consumer fee passthrough considerations for Bead wallet and crypto tenders. It is not legal or compliance advice. All information on this page should be independently reviewed against the specific merchant agreement, applicable platform terms, and the laws of the states where the merchant operates before any decisions are made. ## Bead does not have a consumer fee program This is the first thing to understand, because everything else on this page follows from it. **There is no consumer fee capability anywhere in the Bead platform.** No fee field on a payment, no rate or percentage configuration, no fee schedule input, no calculation, and no consumer-facing disclosure on any Bead-hosted page. Bead's hosted payment page shows a single total and says nothing about how that total was arrived at. **Bead can process a fee you have already calculated.** You size the fee, disclose it, and fold it into the amount you send. Bead receives one computed number and processes it. Bead cannot derive a fee from a rate, cannot apply a fee schedule, and cannot present a fee to a consumer on your behalf. **That distinction decides who carries the exposure.** The determination of what a consumer is charged is made entirely on your side, in your environment, under your disclosure, against your reading of the rules that apply to that merchant, that tender and that state. Bead publishing this page is not Bead approving a fee structure. ### Who is responsible for what | Responsibility | Owner | | ----------------------------------------------------------------------- | ----- | | Deciding whether a fee is permitted for this merchant, tender and state | You | | Sizing the fee, including varying it by tender | You | | Disclosing the fee to the consumer | You | | Presenting or itemizing the fee at checkout | You | | Calculating the final amount | You | | Processing the amount you send | Bead | | Settling the merchant and distributing the partner portion | Bead | If your solution cannot take on the rows marked "You," a consumer fee is not something you can operate on Bead today, and by extension neither is the [Split Funding Program](/split-funding.md). ## Fees have to be sized per tender This is the single most common design mistake, and it is both a commercial and a compliance problem. **Commercially:** Bead's buy rates differ substantially between tenders. A fee sized comfortably for a crypto payment can be well underwater on a buy-now-pay-later transaction. One flat fee across all tenders will overcharge on the cheap ones and lose money on the expensive ones. **For compliance:** permissibility differs by tender as well. A fee that is fine on a crypto payment may be prohibited outright by the platform terms governing a wallet tender. A single fee can therefore be legally wrong at the same time as it is commercially wrong. **On the Split Funding Program there is a third consequence.** Tenders the withheld partner portion cannot cover are silently removed from the consumer's payment page. An undersized fee does not produce an error. It shows up as consumers having fewer ways to pay. Your fee logic needs to vary by tender. That in turn means determining the tender in your own environment before you create the payment, or sizing for the most expensive tender you offer and accepting thinner margin on the rest. **Background** Merchants sometimes ask whether they can pass Bead's processing fee through to the consumer, the same way many businesses handle credit card surcharges today. The answer varies by tender type and is influenced by platform merchant agreements, federal regulatory frameworks, and state law. This page outlines the landscape for each Bead tender so integrators and partners are aware of the considerations involved. Card network surcharging rules (Visa caps, Mastercard registration requirements, equal-treatment obligations) were built around the card brands and do not apply to Bead tenders. When a merchant adds a fee for a Bead payment method, it is generally classified as a convenience fee or service fee rather than a card surcharge. No clear federal framework currently governs convenience fees on emerging payment methods. State law applies regardless of tender type. **How fees are passed through at the API level** There is no separate API field for surcharges or convenience fees. If a fee is incorporated, the adjusted total must be calculated before the payment is created and passed as the amount in the Create Payment request. Example: on a $100.00 order with a 3.5% processing fee, create the payment for $103.50. Bead does not validate or enforce fee structures. For Create Payment details, see [Create Payment](/payments/create-payment.md). Partners on the [Split Funding Program](/split-funding.md) follow the same pattern, with the fee amount sent as the withheld partner portion so the merchant is settled the exact price they billed. The considerations on this page apply directly to those integrations, not by association. **Tender selection and when you can size the fee** Where in the flow the tender is determined decides how you can size a fee at all. | Where tender is selected | What you can do | | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | In your own environment, before calling Bead | Size and disclose a fee specific to that tender. Restrict `tenderTypes` on the payment to the tender the consumer chose. | | On a Bead-hosted page, after the payment is created | You do not know the tender at the point you would normally calculate and disclose. Size a single fee that is valid and sufficient across every tender you offer, or narrow `tenderTypes` yourself before creating the payment. | **If you use a Bead-hosted page for tender selection, read this carefully.** The amounts on a payment are fixed when the payment is created, so there is no point in the flow at which a tender-specific fee can be calculated, disclosed to the consumer, or applied. A single fee sized for the cheapest tender will not cover the most expensive one. Separately, this flow is the harder one for disclosure. If a fee is not permitted for the tender the consumer ultimately selects, or the amount exceeds what a given state allows for it, that is determined after the amount is already fixed. Review this with counsel before offering a mixed-tender hosted page with a consumer fee. A Bead initiative is evaluating consumer fee support for hosted-page tender selection. It is not available today and is not part of the Split Funding Program. **Crypto tenders (BTC Lightning, BTC on-chain, USDC on Base, USDC on Solana)** No federal or state law is known to broadly prohibit merchants from charging a convenience fee when a consumer pays with crypto. This is generally considered the most straightforward of the Bead tender types from a fee passthrough perspective. Merchants should still review applicable state law and disclose any fee to the consumer at the point of sale. **PayPal** The [PayPal User Agreement](https://www.paypal.com/us/legalhub/useragreement-full) restricts surcharging on PayPal transactions while permitting a handling fee under conditions, including that it does not operate as a surcharge and is no higher than the handling fee charged for non-PayPal transactions. Merchants should review their specific PayPal merchant agreement alongside that language to understand what their arrangement permits. **Venmo** Based on Bead's review of Venmo's merchant terms, Venmo prohibits merchants from charging customers any surcharge or additional fee for completing transactions using Venmo. There is no documented carve-out for a consistently applied flat fee. Merchants should review their specific signed Venmo merchant agreement before drawing any conclusions about what is permitted for their integration. **Cash App Pay** Cash App's publicly available terms do not address merchant surcharging directly. Fee passthrough permissibility is governed by the signed merchant agreement. Merchants should review their specific agreement before drawing any conclusions about what is permitted. **Klarna** BNPL products in the United States sit at the intersection of consumer lending law and payments regulation. Adding a merchant fee on top of a Klarna transaction may trigger disclosure obligations under applicable law, independent of what Klarna's merchant agreement says. Merchants should obtain dedicated legal review before drawing any conclusions about fee passthrough for Klarna transactions. This applies to both percentage-based fees and flat fees. **State law considerations** State law applies on top of platform terms and affects what merchants can charge consumers regardless of tender type. The following states have considerations relevant to consumer fee passthrough. | State | Consideration | | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | Connecticut, Massachusetts, Maine | Outright ban on consumer surcharging | | California (SB 478, effective July 2024) | Fees must be included in the advertised price. Itemized surcharges at checkout create compliance exposure regardless of tender type. | | Minnesota (effective January 2025) | Broad pricing transparency rule that applies beyond card tenders. Same practical effect as California. | | New York, New Jersey | Permitted in principle, but the fee may not exceed the merchant's actual cost. | | Colorado | Capped at 2% | | Texas | Prohibited by statute, but a federal court found the prohibition unconstitutional. Enforcement posture remains unclear. | Merchants operating in multiple states should be aware that California and Minnesota's pricing transparency rules are broad enough to affect non-card tenders. All state law considerations should be reviewed with qualified legal counsel for the merchant's specific operating footprint. **Summary by tender** | Tender | General awareness | Notes | | ------------------ | ---------------------------------------- | ------------------------------------------------------------- | | Crypto (BTC, USDC) | No known broad prohibition | Disclose at point of sale; review state law | | PayPal | Handling fee permissible with conditions | See PayPal User Agreement; review specific merchant agreement | | Venmo | Merchant terms prohibit surcharges | No flat-fee carve-out confirmed; review signed agreement | | Cash App Pay | No public position available | Review signed merchant agreement | | Klarna | Consumer lending law applies | Requires legal review; conditions vary by agreement | **Related** * [Split Funding Program](/split-funding.md) * [Create Payment](/payments/create-payment.md) * [Managing Tender Types](/entity-management/terminal-management/managing-tender-types.md) * Tender Types * [Alternative Payments](/reference-guide/enumerations-and-schemas/tender-types/alternative-payments.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/faqs-and-troubleshooting/payments-faqs/consumer-fee-passthrough-for-wallet-and-crypto-tenders.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.