How to Choose a Crypto Payment Gateway: 15 Questions That Matter

Most teams evaluating a crypto payment gateway start with a spreadsheet: fees in one column, supported coins in another, blockchain networks in a third. That comparison answers a real question, just not the one that decides whether the integration survives contact with growth. Whether a provider can accept a transaction is close to solved everywhere by now. What separates one gateway from another shows up after the customer has already clicked pay - how the transfer gets verified, what happens when a block is reorganized, whether a retried API call can double-charge someone.

Payment infrastructure is a choice much closer to picking a cloud provider than picking a shopping-cart plugin. A plugin either works or it doesn't, and swapping it out costs an afternoon. Infrastructure has failure modes you only discover under load, and migrating off a bad choice after a year of production traffic is a project, not a config change.

Fees and coin counts still matter, just as separate decisions. Which assets and networks to accept is its own question - a stablecoin's price stability trades against a network's fee and confirmation profile, and most businesses end up supporting several of each (Which Assets and Networks to Accept). So is the shape of how you receive funds: a checkout address and a standing per-customer balance solve different problems (Payments vs. Static Wallets). Neither decision tells you whether the provider stays trustworthy at ten times your current volume. That needs a different framework.

A framework built around what happens after "Pay"

Fifteen questions cover that territory. Grouped by who in your organization actually deals with the answer, they split into what happens to the payment itself, what happens when something breaks, what your engineers will maintain, and what finance will have to reconcile. None of the fifteen shows up on a pricing page.

What happens to the payment

Payment lifecycle. A gateway that reports every payment as pending then completed is hiding several questions inside one flag: was the transfer detected, does the amount match, is it safe to treat as final. Ask what states a payment can move through and what triggers each transition. A vendor whose only answer is a single "completed" webhook, no matter how the money actually arrived, has not built a lifecycle - it has built a boolean with a friendly name. Suward reports status alongside an independent subStatus (awaitingPayment, confirming, overpaid, underpaid, complianceHold), so the two never collapse into each other.

Confirmation policy. Ask whether the confirmation threshold is a number baked into the product, or a value you can reason about per network and risk level. Proof-of-work and proof-of-stake chains fail differently - one accrues safety with block depth, the other has a finality checkpoint - so a single global "one confirmation is enough" rule is a red flag no matter which chain it's applied to. Suward calibrates requiredConfirmations per network and exposes the table through GET /v1/blockchains, so your integration reads a status instead of reimplementing the math (Confirmations, Finality & Reorgs).

Settlement model. Ask whether the provider distinguishes "safe to ship" from "safe to withdraw." A provider with only one terminal state is asking you to apply a treasury threshold to a twelve-dollar subscription, or a subscription threshold to a six-figure deposit. Suward splits the two into accepted (confirmed, credited, not withdrawable) and success (irreversible, withdrawable), and leaves your code to decide which action each one gates (Every Payment Is a State Machine).

Pricing transparency. Ask for exact net proceeds before the customer pays, returned by an API call rather than estimated from a rate card. A network fee described as "variable," with no endpoint to quote it, is a red flag. POST /v1/payments/quote returns the service fee, the network fee, the gross the customer pays, and the net you receive, before anything is created - quotedPrice locks the moment the payment exists, so the quoted figure is the figure that settles.

What happens when something breaks

Blockchain monitoring doesn't stop the instant a transfer is first seen. Ask whether the provider keeps watching the block that transfer landed in until the payment is actually credited, or treats "seen in the mempool" as equivalent to "paid." The second answer is built for a demo, not a live network under load.

Ask directly what happens to a credited balance if the block containing that transfer gets reorganized out of the canonical chain. "That basically never happens" is not an answer; it's the absence of one. Suward never credits a balance before a payment reaches accepted, so a reorg that hits earlier has nothing to undo, and the payment is re-verified against the new chain automatically.

Balance consistency is easy to fake in a demo: ask whether a webhook can report accepted while the balance API still shows the old figure, even briefly. That gap is where nightly reconciliation jobs get invented. Suward moves a payment's status and its balance change as one write, so there's no window where the two can disagree.

Compliance, in this group, is about timing rather than existence. Ask when screening runs, not just whether it does. A transaction that lands in your dashboard and gets spent against before it's flagged means screening ran after the money already moved - your problem to claw back, not the provider's. Every incoming transaction on Suward is screened before crediting; a hold or a rejection both leave nothing credited.

What your engineers will actually deal with

Idempotent APIs. Ask what happens when a create-payment call times out and your server retries it with the same reference. If the answer involves a separate idempotency-key header you have to invent and manage yourself, that's extra plumbing on your side. Suward ties idempotency to externalId directly: a duplicate create returns 409 with the same field you were already sending.

Webhook security. Ask how you're supposed to verify a notification actually came from the provider, and over exactly what bytes. Checking the sender's IP address is not signature verification. Suward signs every event with Ed25519 over the raw request body and checks the timestamp against a 300-second replay window (Webhooks and Idempotency).

Developer experience. Ask how long it takes to go from an account to a payment in a terminal status - no support ticket, no real wallet needed. A sandbox that needs a sales call before you see a response body says something about how support will feel later. Suward's quickstart gets a first payment to success in about ten minutes; a simulate endpoint drives one through its statuses without touching a real chain.

Documentation. Ask whether the docs explain why a design decision exists - two acceptance stages instead of one, idempotency riding on your own reference instead of a header - or whether they're an auto-generated endpoint list. An engineer debugging a stuck payment at 2 a.m. needs the reasoning, not just the shape.

What finance and ops need to see

Operational visibility means a non-engineer can look at a stuck payment and understand why, without anyone querying a database on their behalf. A dashboard where "processing" quietly covers three unrelated causes is a support queue waiting to happen.

Scalability is about what changes between ten payments a day and ten thousand. A rate limit or a per-payment cap that assumed you'd stay small is something you want to find during a contract review, not a real settlement. Suward caps a single payment at the equivalent of $60,000 and publishes that figure, so it's a planning input rather than a surprise.

Reliability philosophy isn't a box on a feature list. Ask the provider's team a genuinely hard operational question - what happens during a reorg, on a duplicate webhook delivery - and listen for whether the answer is about speed or the failure mode itself.

Five mistakes that surface after the integration ships

None of these show up in a demo. They show up months later, at volume, usually during an incident.

Picking the cheapest rate instead of the most reliable rail. A tenth-of-a-percent difference in service fee is real money at scale, but it's a rounding error next to a duplicate credit or a compliance hold discovered after the goods already shipped. Compare reliability first, then negotiate price against a shortlist.

Treating detection as completion. A transaction in a block explorer means it was broadcast and included somewhere, not that the inclusion will hold. A balance credited on first sighting, before any confirmation policy has run, reintroduces exactly the reorg risk that policy exists to absorb.

Applying one confirmation threshold to every asset and ticket size. A fifteen-dollar download and a two-thousand-dollar electronics order don't carry the same risk, and neither does a stablecoin transfer on a fast, cheap network versus a large deposit on a network whose finality model needs far deeper confirmation for the same guarantee. A single hardcoded threshold is too slow for the small orders or too fast for the large ones.

Bolting compliance on after the payment lands. Screening that runs after funds are already spendable means you absorb the loss if something fails it later. The fix is infrastructure where screening runs before crediting, on every transaction, with no opt-out.

Building the blockchain layer in-house. Nodes need constant care, and so do confirmation tracking and reorg recovery under real load, not a testnet. That's a real engineering program, not a weekend project, and most companies competing on their own product don't want it on their roadmap once they've priced out what running it well actually costs.

Compliance belongs inside the payment, not next to it

Compliance scoped as a separate service — a case-management tool, a monthly report, a team reviewing flagged transactions after the fact — runs backwards: the moment that matters is before a transaction becomes spendable, not after. → The Complete Guide to Crypto Payment Gateways covers how Suward screens every transaction before crediting, and what complianceHold and complianceRejected actually mean.

Final thoughts

The competitive question for crypto payments stopped being whether a business accepts them. Enough businesses already do that the answer is assumed. What varies now is whether the infrastructure behind that acceptance holds up once real volume and real money show up together.

Fifteen questions won't fit on a pricing page, and that's the point. Ask about the states a payment moves through, and what happens when a block gets reorganized underneath one. Find out whether a retried request can double-charge anyone. Ask when compliance actually runs - before the money moves, or after it already has. Providers worth building on have specific, boring answers to all three; the ones optimized for a fast demo don't.