← All posts

Trustware: How to Accept a Fixed-Price Crypto Payment Instead of an Open-Ended Deposit

TL;DR: Not every deposit should let a user enter any amount. A checkout, an invoice, or a subscription charge needs a specific price, in your destination asset, regardless of what chain or token the payer is holding. Trustware's route configuration supports this directly, a fixed input amount or minimum/maximum output constraints, without your app building custom amount validation.

What's the difference between an open deposit and a fixed-price payment?

An open deposit lets a user choose any amount to move into your destination asset, suited to funding a balance or topping up an account. A fixed-price payment needs the transaction to resolve to a specific amount, or within a bounded range, suited to a checkout, invoice, or subscription charge where the price isn't negotiable.

How to configure a fixed-price payment

Step 1, decide whether you need a fixed amount or a bounded range

A checkout with a set price needs an exact fixed amount. A donation flow or a flexible invoice might instead need a minimum and maximum, allowing some range while still enforcing bounds.

Step 2, configure the constraint in your route options

For a fixed price, set routes.options.fixedFromAmount to lock the widget's amount input to a set USD value. For a bounded range instead, set routes.options.minAmountOut and routes.options.maxAmountOut to constrain the destination amount without fixing it exactly.

Step 3, keep your destination configuration explicit

Pair the amount constraint with your existing routes.toChain and routes.toToken configuration, so the payment resolves to a specific price in a specific destination asset regardless of what the payer holds or which chain they're paying from.

Step 4, confirm the constraint is enforced before you rely on it for billing

Test the fixed or bounded configuration end to end, including what the widget does if a user attempts an amount outside the configured bounds, before using it for anything billing-critical.

The Trustware view, amount validation shouldn't be your app's problem to solve twice

Building your own amount validation on top of an open-ended deposit flow means duplicating logic the routing layer could enforce natively. Configuring the constraint once at the route level means your app doesn't need a separate validation pass after the fact.

A contrarian take, "let the user pick any amount, we'll validate after" is a common but avoidable pattern

It's tempting to accept any deposit and reconcile the correct price afterward, especially early on. That pattern creates support tickets and manual refund handling the moment someone pays the wrong amount, work that a fixed or bounded configuration prevents at the source instead of cleaning up afterward.

What to check before relying on this for billing

  • Does your use case need an exact fixed amount, or a bounded range?
  • Have you tested what happens when a user attempts an amount outside the configured constraint?
  • Is your destination chain and token configuration stable across the payments you're processing?
  • Are you handling the success and error events to confirm a payment actually completed at the expected amount?
  • Does your reconciliation process cross-check the configured constraint against what actually settled?

See the Trustware docs for current route option details.

FAQ

Can I lock a deposit to an exact price?

Yes, routes.options.fixedFromAmount locks the widget's amount input to a set value.

Can I allow a range instead of an exact amount?

Yes, minAmountOut and maxAmountOut constrain the destination amount within bounds without fixing it exactly.

Does the payer need to hold the exact destination asset?

No, the payer can hold any supported source asset; the fixed or bounded configuration applies to the resolved destination amount, not the source.

What happens if a user tries to pay outside the configured bounds?

{{CITE: confirm current widget behavior for out-of-bounds amount attempts before publishing}}

Can this be used for recurring subscription charges?

{{CITE: confirm current support for recurring/subscription-style configurations before publishing}}

Is this available in the headless API as well as the widget?

The route options, including fixedFromAmount and min/max constraints, are part of the shared routing configuration used by both the widget and the headless core API.

How to decide which constraint fits your use case

Use a fixed amount for a set price like a checkout or subscription charge. Use a min/max range when some flexibility is acceptable but bounds still need enforcing, like a donation or flexible invoice.

See trustware.io for current configuration options.