Payment channels
How do I accept card payments?
Choose hosted checkout for most card flows, or embedded card collection when your app needs full UI control.
For most teams, card payments should start with hosted checkout. Use embedded card collection only when your product needs card entry inside your own UI.
Cards work on hosted checkout (fastest) or embedded flows with Payment Elements and POST /charge/card.
Which card flow should I use?
| Flow | Use when |
|---|---|
| Hosted checkout | You want the fastest, safest card experience |
| Payment links | You want a card-capable shareable URL |
| Embedded card charge | You own the checkout UI and can handle client confirmation |
| Payment Elements | You want reusable card UI primitives in your application |
Hosted checkout (recommended)
- Create a checkout session.
- Customer selects Card and enters details on lomi.. page.
- Handle 3D Secure when the test card or issuer requires authentication.
- Verify with webhooks before fulfilling.
Embedded card charge
Embedded card charges (POST /charge/card) and Switch charges (POST /charge/switch) are not available yet and currently return 503 service_unavailable. Use hosted checkout for cards today.
POST /charge/card→ receiveclient_secret.- Confirm with Payment Elements on your site.
- Poll or webhook for final
transaction_status.
See Charges API and the direct charge reference app.
Sandbox test cards
| PAN | Behavior |
|---|---|
4242 4242 4242 4242 | Success |
| Decline / auth test numbers | See Sandbox payments |
Never use real card numbers in test mode or test numbers in live mode.
Safety notes
- Never handle secret keys in a browser or mobile app.
- Treat
client_secretvalues as short-lived sensitive capabilities. - Use publishable keys only where the card flow requires them.
- Confirm final state from webhooks or server-side API reads.