SwapSS learn

Merchant crypto payment reconciliation

The hard part of crypto payment acceptance is not only creating an invoice. It is proving later which order was paid, which event was delivered, which amount was credited, and what happened when a webhook failed.

Use merchant order IDs and payment IDs together

The merchant order ID connects the payment to the store. The payment or invoice ID connects it to SwapSS Pay status, webhooks, and support evidence. Store both.

Treat webhooks as notification, not final authority

A webhook tells your system that something changed. Your fulfillment logic should dedupe by event ID and be able to poll the invoice status if a webhook arrives late, arrives twice, or is missed.

Make duplicate handling boring

Retries are normal. A production integration should store event IDs, invoice IDs, status, credited amount, timestamps, and fulfillment result. Running the same event twice must not ship an order twice.

  • Store every webhook event ID before side effects.
  • Use idempotency keys for invoice creation.
  • Keep a manual review path for amount, asset, or network mismatches.

What SwapSS Pay docs should answer

The docs should show invoice creation, signed webhooks, idempotency, status polling, payment statuses, refunds, payouts, and balance movement. That is the crawlable proof a developer needs before trying the API.