Payments

Crypto Payment Integration

Accepting crypto is one API call. Knowing which order a payment belongs to, what happens on an underpayment and how you refund it is the actual project.

Cancel any week. Last week refunded if we didn’t blow you away. No hours tracked.

  • PoS + Web Multi-chain, wallet-agnostic crypto checkout for shops, restaurants and hotels, pilot-ready for merchant integration See the case study
  • Dual rail Fiat and crypto payments through one signed-webhook handler on a live RWA commerce platform See the case study

What We Do

The payment provider handles the chain. Your system still has to match every payment to an order, survive duplicate callbacks and explain the numbers to finance.

Checkout and Point of Sale

Crypto at the online checkout and at the counter, without a crypto lesson for the customer.

  • Embeddable web checkout
  • PoS flows for shops, restaurants and hotels
  • Wallet-agnostic on desktop and mobile
  • Pay in the token the customer holds, settle in the one you want

Payment Provider Integration

Processors, facilitators and on-ramps chosen against your markets, not their marketing.

  • Crypto processors and stablecoin providers
  • Fiat on-ramps for customers without crypto
  • x402 for paid APIs and agent payments
  • Provider choice against fees, coverage and eligibility

Webhooks and Payment State

Every callback verified, deduplicated and tied to exactly one order.

  • Signature verification on every webhook
  • Idempotent handlers that survive retries
  • Confirmation, underpayment and expiry states
  • One correlation ID from invoice to settlement

Reconciliation

Numbers your finance team can close the month on.

  • On-chain receipts matched to orders and invoices
  • Fiat value recorded at payment time
  • Fees, gas and spreads itemised
  • Exports for your accounting system

Refunds and Exceptions

On-chain payments have no chargeback, so refunds have to be designed.

  • Refunds as new, approved outbound transfers
  • Partial refunds and overpayment returns
  • Wrong-chain and wrong-token deposit handling
  • Approval rules and an audit trail for every payout

How we approach crypto payments

We buy what is commodity and build what touches your orders. On Scramble Pay we forked a proven DEX aggregator for the swap layer and put the budget into an embeddable checkout and merchant dashboard for PoS and web. On LivLive the fiat and crypto rails ran through one signed-webhook handler, with a cloud KMS holding the only key that signs mints and payouts. If your customers need a wallet product of their own, that is Web3 wallet development. Syncing settled payments deep into an ERP or CRM is API integration. And if what customers pay for is a tokenized asset, the issuance side sits with asset tokenization development.

When you should not accept crypto

If your customers are not asking for it, a crypto button adds compliance work and support tickets without adding revenue. If a hosted processor already covers your chains, tokens and markets, use its plugin and spend nothing on custom work. Custom integration earns its cost when you run your own checkout or PoS, need payments matched to your own order system, sell into markets a processor does not cover, or settle in stablecoins between businesses. Be honest about the compliance side too: merchant onboarding, sanctions screening, tax and accounting obligations do not disappear because the payment is on-chain. We engineer for them; we do not give legal advice.

Want to accept crypto without breaking your books?

Tell us where you sell, what you want to accept and where the money should end up. We will name the smallest integration that works, including a plugin if that is enough.

FAQs

Honest answers about crypto payment delivery

End any week, with one message. No notice period, no exit interview, no fine print. We invoice weekly, so the most you’re ever committed to is the current week.
It’s in your contract: tell us, and we refund that week. No questions, no invoices to dispute, no calls to escalate. The only rule: refunds apply to the most recent week.
Because hours are the wrong metric. If we optimize for hours billed, we do not optimize for your outcome. The deal is simpler: every week has a defined result, and we earn the next week by delivering it. You pay for progress against that result, not for a timesheet.
We work with operators, not lottery winners. If a request would require breaking physics, the law, or a third party’s systems, we say so, and if we can’t align, we walk. The guarantee is mutual: you can fire us any week; we can also fire ourselves.
Often a processor plugin is enough, and we will say so. You need custom work when payments have to match orders in your own system, when you run a custom checkout or PoS, or when the processor does not cover your chains, tokens or markets. Most real projects combine a processor for the chain with our code for order state, reconciliation and refunds.
There is no chargeback. An on-chain payment is a push payment, so a refund is a new transfer from you to the customer unless your processor offers its own refund workflow. We design who approves it, which address and token it goes to, how fees are handled and how it is recorded, before the first customer asks.
The one your customers hold and your provider can settle for your entity and markets. Check eligibility before engineering: Open USD, for example, launched in September 2026, but its partner policy excludes promotion in the EEA, which matters for any European-facing product. Our Open USD guide shows the checks we run on any new asset.
x402 is an open protocol built on HTTP’s 402 Payment Required response, so software, including AI agents, can pay for an API call or a resource. You need it when machines pay per request; you do not need it for a normal shop checkout. Our x402 comparison sets the facilitators and processors side by side.
Every callback is signature-verified, deduplicated by an idempotency key and moved through an explicit state machine: pending, confirmed, underpaid, expired, refunded. A settlement retry must never trigger a second fulfilment. One correlation ID runs from invoice to chain confirmation to delivery, so support can say where a payment is without opening a block explorer.
// Get to know us

Get to know us

Long-term relationships over quick wins.