How it works
- Your frontend calls the Checkout SDK with a deposit amount and destination.
- The SDK calls your signer endpoint — a server-side route you build that signs each payment request with your ECDSA private key.
- The SDK opens a modal iframe containing Blink’s hosted payment UI.
- The user authenticates, connects a wallet, and completes the payment inside the iframe.
- On completion, the SDK returns a
DepositResultwith the transfer ID and status.
What you need to build
| Component | Where | What |
|---|---|---|
| Signer endpoint | Your server | An HTTP endpoint that validates payment requests, signs them with your private key, and returns a SignerResponse. |
| Checkout integration | Your frontend | A few lines of code using the @swype-org/checkout SDK (vanilla JS or React) to trigger the payment flow. |
Key concepts
| Term | Definition |
|---|---|
| Merchant Signer | A server-side endpoint you build that creates and cryptographically signs payment requests. The private key never leaves your server. |
| Payload | A base64url-encoded JSON string containing payment parameters (amount, chain, address, token, idempotency key, expiration). |
| Signature | An ECDSA P-256 SHA-256 signature over the payload string, base64url-encoded. Blink verifies this against your registered public key. |
| Idempotency Key | A UUID v4 generated per payment request. Prevents duplicate transfers if the same request is submitted twice. |
| Hosted Flow | Blink’s payment UI that opens in a modal iframe. It handles user authentication, wallet connection, and the actual transfer. |
| Checkout SDK | The client-side library (@swype-org/checkout) that orchestrates the signer call and hosted flow lifecycle. |
Next steps
Quickstart
Get a working integration in 5 minutes.
Architecture
Understand the full payment flow in detail.