Skip to main content

Performance optimization

1. Warm up cache

Warm up token detection cache at app startup:

2. Fast mode

Skip detection for tokens with a known payment type:

3. Reuse requirements

For fixed-amount APIs, reuse the requirements object:

Security

1. Amount cap

The client must set a maximum payment amount:

Multi-chain deployment

Create separate instances per chain

Error handling

Handle by error stage

Provide different handling strategies for different stages:

Unified error handling

Client-side error handling

Server-side error handling

FAQs

Q1: How to choose the right authorization type?

A: Use auto detection (default) or follow suggestions:
  • EIP-3009: Token-native support (e.g., USDC) — most efficient
  • EIP-2612 Permit: Standard ERC-20 — great compatibility
  • Permit2: Need generalized authorization management — most flexible

Q2: How to handle tokens with different decimals?

A: Be careful with units (wei):

Q3: How to handle payment failures?

A: Use different strategies for different stages:

Q4: When should I return 500 instead of 402?

A:
  • 402: Client-side issues (parse/verify failed) — the client must fix
  • 500: Server-side issues (settle failed) — may be transient (network, gas, etc.)
Settlement failures are typically temporary server issues; return 500 and suggest retrying later.

What’s next

Examples

See more real-world examples

Server SDK

Learn the server SDK in depth