Crypto payments and chargebacks

Crypto payment chargebacks do not follow card-scheme rules. After a blockchain payment reaches the required finality, no issuer, acquirer, or card network can debit the merchant by reversing that transaction. Returning funds requires a new transfer the merchant initiates itself.

That removes one category of payment loss. It does not remove fraud, customer complaints, fulfillment mistakes, underpayment, or legal obligations. Merchants still need a clear decision path for when to fulfill and when to refund. Review the crypto invoicing lifecycle and available Paymos payment surfaces before assigning those controls.

Why can a card payment be charged back?

A card payment runs inside a contractual network. Cardholders, issuers, acquirers, merchants, and schemes each have defined roles. A cardholder can ask the issuer to dispute a transaction. The scheme's rules define reason codes, evidence requirements, response windows, liability, and the adjustments that move value through the card system.

For the merchant, the dispute can arrive after the order was fulfilled. Responding can require proof of authorization, delivery, customer communication, and service use. A lost case can include the payment amount and the operational cost of handling it.

This mechanism is not a technical rollback of a bank ledger entry. It is a rule-governed financial adjustment made by institutions that participate in the same card network. Blockchain payments do not include those card-network actors or their chargeback authority.

Why is a finalized blockchain payment different?

A blockchain transfer starts with the sending wallet's authorization. The network then incorporates it into transaction history. Payment processors decide when that transfer has reached enough finality to credit the invoice. Once that threshold is met, a card issuer cannot invoke scheme rules to remove it from the merchant's balance.

Finality does not mean every chain behaves identically. Some networks provide explicit protocol-level finality, while others rely on increasing confidence as blocks build on the transaction. Paymos therefore sets confirmation policy by both network and payment amount. Larger payments can require a stronger threshold than smaller payments.

The control point is fulfillment. A transaction hash, wallet screenshot, or early detection signal is not enough. Release the product only after the invoice reaches its final paid state. The blockchain confirmations guide explains why that threshold changes by network and payment amount.

Which risks remain without card chargebacks?

Removing card-style reversals narrows payment risk. It does not eliminate that risk. A merchant still needs controls for:

• Stolen-wallet payments: blockchain authorization proves control of a key, not the rightful use of that key.
• Account takeover: an attacker can buy through a compromised customer account.
• Fulfillment fraud: a buyer can falsely claim that digital access or goods were never delivered.
• Wrong payment details: a customer can use the wrong asset, network, address, or amount.
• Social engineering: a fraudster can redirect a refund to an address they control.
• Commercial disputes: product quality, delivery, and contract claims still exist.

These risks move resolution outside the card-scheme channel. Merchant support, contractual terms, marketplace policy, and applicable law govern the outcome instead.

How should underpayment be handled?

Underpayment should follow the invoice policy rather than a support agent's judgment. Tolerance is a percentage set per project: a new project starts at 0.1%, the ceiling is 2%, and 0% means strict matching. A payment inside the tolerance completes the invoice, and the merchant settles the amount received. The difference is not funded.

A single-payment invoice below the threshold remains underpaid. A multi-payment invoice can stay open while the customer sends the remainder. Neither outcome should be silently converted into a fully paid order outside the configured rule.

This matters to dispute prevention. The checkout and order record should show the requested amount, received amount, tolerance, and final invoice state. A customer service team can then explain the outcome from recorded payment facts instead of reconstructing it from screenshots.

What is the correct crypto refund workflow?

A crypto refund is a new outbound transaction. It needs its own amount, asset, destination, approval, network fee, transaction reference, and audit record. The original payment remains part of the blockchain history and the merchant's invoice record.

Use a controlled sequence:

1. Match the request to the original order and invoice.
2. Verify the received asset and amount from processor records.
3. Apply the merchant's refund eligibility policy.
4. Verify the destination through a trusted customer channel.
5. If needed, withdraw the asset from Paymos to a merchant-controlled, whitelisted treasury address.
6. Send the refund as an outbound transfer to the whitelisted destination.
7. Record the approval and resulting transaction reference with the case.

Do not copy an address from an unsolicited message. Verify the refund destination through the merchant's own support and approval process before sending funds.

Which Paymos controls apply before a refund?

Paymos secures the outbound transaction, not the decision to refund. It sends withdrawals only to merchant-controlled, whitelisted blockchain addresses, and an empty whitelist disables withdrawals. Adding or removing a withdrawal address is its own recorded action, and on an account with a second factor enrolled it also takes a step-up challenge — an account without one has no factor to challenge, so that part of the control follows the merchant's own 2FA setting. A global outbound freeze, or a freeze for a specific asset-and-network pair, can also be applied.

Outgoing transactions are signed on isolated infrastructure. Destination whitelisting and outbound freezes remain independent controls around that signing path.

These controls end when the asset reaches the merchant-controlled address. The merchant's own policy, approval process, and destination checks govern the separate refund transaction. Paymos does not decide whether a customer deserves a refund and provides no direct customer-refund, payer self-service refund, or dispute flow.

How should payment status control fulfillment?

Fulfillment should depend on an authenticated final invoice status, not a transaction hash, wallet screenshot, or browser callback. Paymos signs webhooks so the merchant can verify the event before updating an order. Process each event idempotently because a delivery retry can repeat a status that the application has already recorded.

Store the verified event before running fulfillment work. If an internal job fails afterward, retry the job from that durable record without changing payment truth or issuing the order twice. The webhook verification guide contains the signature format and implementation steps; this article only needs the operational rule that a verified final status unlocks fulfillment.

What should a merchant refund policy contain?

A useful policy answers seven questions. It covers eligible reasons, request deadlines, proof, refundable amount, network-fee treatment, destination verification, and approval authority. It should also explain that a blockchain refund is a new transaction and cannot erase the original payment.

Separate payment finality from commercial fairness. “No chargebacks” should never become “no refunds.” A merchant can maintain a customer-friendly return policy while preserving control over who authorizes the outbound transfer.

Support staff need one complete case record. It should link the customer, order, invoice, inbound transaction, decision, approved destination, outbound transaction, and communication history. That record replaces the evidence package a card network would otherwise define and gives the business a consistent process across every supported blockchain.

What changes in the merchant risk model?

Crypto changes the merchant's payment-risk controls. The business moves from reactive scheme disputes to proactive fulfillment and refunds. It no longer waits for an issuer to debit a finalized payment, but it must decide finality correctly, protect customer accounts, verify refund destinations, and maintain a defensible service record.

The best operational rule is narrow. Trust the processor's final invoice state for payment and the merchant's documented policy for the commercial outcome. Do not let a transaction hash bypass confirmation, and do not let the absence of a chargeback channel bypass customer support.

That separation preserves the central settlement benefit. Card-style reversal ends after finality, but payment risk and merchant responsibility remain.