How Crypto Payments Work: Wallet to Settlement (2026)

A crypto payment moves an accepted asset from a payer's wallet to a merchant balance. The business creates an invoice, the payer sends funds to its receive address, the network includes the transaction in a block, and the processor applies a confirmation policy before crediting the merchant.

Seeing a transaction is not the same as settlement. Network propagation, block inclusion, and finality are separate events, so a merchant should fulfill from the processor's confirmed result rather than from a wallet timer or a fixed promise.

How does a crypto payment begin?

The merchant's backend or storefront creates an invoice before presenting checkout. Paymos invoice creation uses a caller-supplied external_order_id, which links the merchant's order to the payment request. If the same identifier is reused, Paymos returns the existing invoice.

That behavior gives both systems one stable business reference. The merchant should retain the relationship between its order and the existing Paymos invoice for reconciliation.

Treat a repeated transport request as another attempt for the same order. Reuse the original value after a timeout, and assign a different value only when the customer starts a new purchase.

Why does each invoice receive its own address?

Paymos derives a dedicated deterministic address for every invoice. A transfer arriving at that address can therefore be associated with the invoice without relying on the amount alone. Separate addresses also make on-chain reconciliation clearer when two customers owe the same value.

Outgoing Paymos transactions use MPC threshold signing with a 2-of-3 quorum. No single participant can authorize a transfer, and the complete private key is not assembled or stored in one place. This signing model applies to outgoing transactions; the payer still signs the incoming payment with the payer's own wallet.

What happens when the payer sends the transaction?

The wallet builds a transfer to the invoice address and signs it with the payer's private key. It then broadcasts the signed transaction to peers on the selected network. The payer's wallet covers the network fee required to send the payment.

The required network fee follows the selected network's rules and changes with network conditions. It is separate from the Paymos processing fee. Paymos settles the merchant in the accepted asset rather than forcing a conversion to BTC, ETH, or fiat.

What happens on networks that use a mempool?

On networks that expose a mempool, it is a node's local view of valid transactions that have not yet entered a block. Nodes exchange transactions with peers, but propagation takes time and local admission policies can differ. Two nodes can therefore show different pending sets at the same moment. Other networks can expose pending work through different mechanisms, so this stage is not universal.

This distinction matters when a wallet reports that it broadcast a transaction. Broadcast means the wallet sent the transaction to peers; it does not prove that every node has received it, that a validator has included it, or that the payment has reached finality.

What changes when the transaction enters a block?

Block inclusion places the transaction in the chain history observed by the network. It is stronger evidence than a local pending view, but inclusion and finality are not identical. Different networks use different consensus rules and confirmation signals.

A processor follows the selected network and associates the included transfer with the invoice address. The merchant still waits for the processor's confirmation policy before fulfilling the order. A wallet's first inclusion notice should not replace that business rule.

Keeping those stages separate prevents a single block notification from becoming an accidental fulfillment trigger.

How does Paymos decide when to credit the merchant?

Paymos confirmation policy depends on both the network and the payment amount. Smaller payments can require fewer confirmations, while larger payments can require a stronger finality threshold. Current blockchain conditions determine how long that threshold takes to reach.

There is therefore no universal settlement time or block count for every payment. The operational rule is straightforward: keep the order unfulfilled until Paymos reports the payment as confirmed, then reconcile it against the original invoice.

This rule keeps merchant fulfillment consistent without copying one network's timing assumptions into another payment route.

How should the merchant secure notifications?

After confirmation, Paymos credits the accepted asset to the merchant's asset balance. For integration notifications, Paymos provides webhooks authenticated with HMAC-SHA256 through the X-Webhook-Signature header. The receiver can verify that a notification was signed with its webhook secret.

One Paymos delivery cycle makes 11 total attempts over approximately 16 hours, with retry delays increasing up to eight hours. If an event remains undelivered, it can be replayed manually. These delivery facts describe reach and recovery without assuming a particular internal queue or database design.

What happens when the payer sends too little?

Underpayment handling follows the project's percentage tolerance. The default is strict matching with 0% tolerance. A payment within the configured tolerance completes the invoice, and the merchant receives the amount actually paid.

Below the threshold, a single-payment invoice becomes underpaid. A multi-payment invoice can remain open while the payer sends the remainder. This is a confirmed Paymos rule; the article does not assume undocumented outcomes for overpayments, late transfers, or chain reorganizations.

The merchant should retain the amount actually received and the invoice result so fulfillment follows the configured rule rather than the amount originally expected.

What should the merchant integration enforce?

The integration should keep three boundaries explicit. First, reuse the order's external_order_id and retain the relationship between the order and its Paymos invoice. Second, treat wallet broadcast and block inclusion as progress rather than final settlement. Third, verify the webhook HMAC before acting on the notification.

Order fulfillment should follow the confirmed payment result and remain safe if the merchant retries its own work. If webhook delivery needs recovery, Paymos provides repeated delivery attempts and manual replay rather than requiring the business to infer settlement from elapsed time.

How is this different from a card payment?

A card payment asks an issuer and card network to authorize a charge, then follows the acquirer's settlement schedule. A crypto payment transfers an accepted asset on-chain, and its timing follows the selected network, payment amount, current conditions, and confirmation policy.

Once an on-chain payment reaches finality, it cannot be reversed through a card-scheme chargeback. A refund is a new outbound blockchain transaction initiated by the merchant. Paymos also settles in the asset received and does not provide a bank-account conversion route.