API endpoint mapping
Create a payment request
- Charge API
- Checkouts API
Key changes
Key changes
- Amount is now a direct string field (not nested in
local_price) - Currency is specified directly (Checkouts API currently supports USDC)
- Network specification is now explicit (defaults to
base) - Redirect URLs have been renamed for clarity
namefield is removed; usedescriptioninstead- Idempotency is supported via
X-Idempotency-Keyheader
List payment requests
- Charge API
- Checkouts API
Key changes
Key changes
- Pagination uses
pageSizeandpageTokeninstead of Commerce’s cursor-based approach - Can filter by status (ACTIVE, PROCESSING, DEACTIVATED, EXPIRED, COMPLETED, FAILED)
- Response includes
nextPageTokenfor retrieving next page - Response key is
checkouts(notdata)
Retrieve a specific payment request
- Charge API
- Checkouts API
Key changes
Key changes
- Use the checkout ID (24-character hexadecimal format)
- No support for retrieval by code (use ID only)
Cancel/deactivate a payment request
- Charge API
- Checkouts API
Key changes
Key changes
- Explicit deactivation endpoint available
- Deactivated checkouts cannot accept further payments
- Status changes to
DEACTIVATED
Response schema mapping
Payment details
| Charge API Field | Checkouts API Field | Notes |
|---|---|---|
id | id | Format changed from UUID to 24-character hexadecimal |
code | N/A | Code not available in Checkouts API |
hosted_url | url | The shareable payment URL |
name | description | Name field replaced by description |
description | description | Same purpose |
pricing.local.amount | amount | Flattened structure |
pricing.local.currency | currency | Flattened structure |
| N/A | network | New field specifying blockchain network |
| N/A | address | New — merchant’s blockchain receiving address |
| N/A | updatedAt | New — timestamp of last status update |
| N/A | settlement | New — fee breakdown (totalAmount, feeAmount, netAmount, currency) |
| N/A | transactionHash | New — on-chain transaction hash (present when COMPLETED) |
expires_at | expiresAt | Same purpose, RFC 3339 format |
metadata | metadata | Same purpose |
redirect_url | successRedirectUrl | Renamed for clarity |
cancel_url | failRedirectUrl | Renamed for clarity |
created_at | createdAt | Same purpose, RFC 3339 format |
timeline | status | Status now a single field instead of timeline array |
web3_data | transactionHash | Transaction hash available directly on the response |
Status mapping
Understanding status transitions is crucial for order fulfillment:| Charge API Status | Checkouts API Status | Description |
|---|---|---|
| NEW | ACTIVE | Payment request is active and awaiting payment |
| SIGNED | ACTIVE | In Checkouts, signing happens within the payment flow |
| PENDING | PROCESSING | Payment detected, awaiting confirmation |
| COMPLETED | COMPLETED | Payment confirmed and finalized |
| EXPIRED | EXPIRED | Payment request expired without payment |
| FAILED | FAILED | Payment attempt failed |
| N/A | DEACTIVATED | Checkout manually deactivated |
Important considerations:
- Checkouts API focuses on the checkout status, not individual transaction status
- Use webhooks for real-time payment status notifications (see Webhooks documentation)
- Once a payment is detected and confirmed, the status changes to
COMPLETED
Webhooks
Charge API webhooks
Commerce provides webhook events:charge:createdcharge:pendingcharge:confirmedcharge:failed
Checkouts API webhooks
Checkouts API supports webhooks for real-time payment notifications:checkout.payment.success- Checkout successfully paidcheckout.payment.failed- Checkout payment failedcheckout.payment.expired- Checkout expired without payment
- Creating webhook subscriptions using CDP API
- Webhook signature verification
- Sample event payloads
If you prefer not to use webhooks, you can also monitor payment status by periodically polling the GET endpoint to check checkout status.
Node.js implementation examples
- Charge API
- Checkouts API