Skip to Content

Accept Crypto Payments

Take stablecoin payments on your checkout — through a hosted page, an embedded React widget, or a direct server-to-server API call. Settlement lands in your KryptoGO-managed receive address; status updates push to your webhook.

Who this is for

PersonaTypical inbound
Small or mid e-commerce shop”We want to accept USDT alongside our existing payment options.”
SaaS billing page”Our subscribers in Asia want to pay in stablecoins instead of card.”
Donation or non-profit page”We want a single link supporters can use to donate crypto with a receipt.”
Marketplace operator”Our buyers should pay our sellers in crypto. We settle the platform fee.”

Not a fit if you need native ETH or Bitcoin payments (we are stablecoin-only), card payments alongside (we do not aggregate card networks), or settlement directly into a self-custodied wallet you control (we settle into a KryptoGO-managed receive address that you can sweep from).

What you can ship today

Three integration paths, ordered from “fastest to ship” to “most flexible”:

PathWhat it isBest for
Hosted checkoutA single URL we host. You redirect the customer; we handle the rest.Merchants without a frontend engineering team, or who want a lift-and-shift checkout flow
Embedded React widget (@kryptogo/kryptogokit-sdk-react)Drop our React SDK into your existing checkout page. The widget opens an in-page modal — no redirect.React-based merchant frontends that want the modal to live inside their existing UX
Direct APIServer-to-server REST calls behind an API key. Your frontend can be anything (or nothing).Backends that prefer to control the UX entirely, or that ship in non-JavaScript stacks

All three paths share the same backend — they create a “payment intent”, the customer pays on-chain, and KryptoGO POSTs status updates to your callback URL.

How it works

1. Your backend creates a payment intent POST /payment/intent { fiat_amount: "100.00", fiat_currency: "TWD", callback_url: "...", ... } 2. KryptoGO returns a payment_intent_id and (optionally) a hosted checkout URL. 3. Your customer pays: - Hosted: redirect to https://pay.kryptogo.com/<payment_intent_id> - Embedded: SDK renders the modal in your page - Direct: your frontend fetches details and renders its own UI 4. The customer signs the on-chain transfer from their wallet. 5. KryptoGO's chain watchers detect the transaction and advance the payment intent state machine: pending → success. 6. KryptoGO POSTs a signed callback to your callback_url on every status change. Verify the HMAC-SHA256 signature in the payload body before acting on it. Respond 200 to acknowledge.

Sample request

{ "chain_id": "arb", "pricing_mode": "fiat", "fiat_amount": "100.00", "fiat_currency": "TWD", "pay_token": "USDC", "callback_url": "https://your-server.com/payment/callback", "order_data": { "order_id": "uid_12345", "item_id": "100" }, "group_key": "subscription_purchase" }

Sample callback (success)

{ "payment_intent_id": "0h39QkYfZps7AUD1xQsj3MDFVLIMaGoV", "status": "success", "payment_chain_id": "arb", "symbol": "USDT", "fiat_amount": "300.0", "fiat_currency": "TWD", "crypto_amount": "2.53", "received_crypto_amount": "2.53", "payment_tx_hash": "0x1234...cdef", "order_data": { "order_id": "uid_12345", "item_id": "100" }, "callback_url": "https://example.com/callback", "timestamp": 1715462400, "signature": "<HMAC-SHA256 of the canonical payload>" }

The merchant must verify the HMAC-SHA256 signature against the canonical payload using the shared secret, respond 200 to acknowledge, and treat the callback as idempotent (the same status change can fire more than once on retry paths).

Status lifecycle

StatusMeaning
pendingIntent created, waiting for on-chain payment
successConfirmed on-chain, funds settled
expiredPayment window closed without funds arriving
insufficient_not_refundedCustomer underpaid; refund pending
insufficient_refundedUnderpayment refunded — refund_tx_hash populated
cancelledMerchant cancelled the intent

Custody model

Settled payments land in your KryptoGO-managed receive address (one per supported chain, automatically provisioned when your organisation is created). This is custodial — see Custody Options. You can sweep settled funds to a self-custodied wallet, leave them in custody, or trigger a fiat off-ramp via a partnered settlement provider — see Off-Ramp Crypto to Bank.

Compliance posture

Payment acceptance inherits our regulated posture: Taiwan VASP, ISO 27001 and ISO 27701 certifications, SOC 2 Type II, Cure53 audit. Address-level AML risk scoring runs inline on every payment based on configurable per-organisation policy. Sanctions screening covers payer addresses. See Compliance & Certifications for the full posture.

Chains and tokens supported today

ChainTokens
ArbitrumUSDC, USDT
BaseUSDC, USDT
OptimismUSDC, USDT
SolanaUSDC, USDT
TronUSDT

Additional chains and tokens are added on request. Bitcoin and native Ether (as opposed to ERC-20 stablecoins) are not part of the payment platform.

Typical integration timeline

PathBucket
Hosted checkout (no frontend code)Under one month — typically a single day once your organisation is provisioned
Embedded React widgetUnder one month — typically three to five days for a team familiar with React
Direct API (server-to-server)Under one month — typically a week for a backend team comfortable with REST and HMAC signature verification

Current scope

  • The hosted checkout app is in production and used by external integrators.
  • The embedded React widget is published on npm and documented in the Crypto Payment docs.
  • HMAC-SHA256-signed callbacks with timestamp-based replay protection are in production for payment intents.
  • Manual refunds (beyond the automatic underpayment refund) are processed through your operations team via Studio. A self-service refund API for partners is on the near-term roadmap.

Talk to us

If you want to accept stablecoin payments and need help scoping which integration path fits your stack, reach our partnerships team via the address on www.kryptogo.tw .

Where to go next

Last updated on