Choose your integration
Von Payments has three integration paths. Pick by how much control you need over the checkout UI and how much PCI handling you want to avoid.
| Checkout | Embedded Fields | Payment Intents | |
|---|---|---|---|
| You build | A redirect + return handler | A page that hosts our iframes | Server-side auth / capture / void / refund |
| Buyer sees | checkout.vonpay.com | Your page, our fields | Whatever you build |
| PCI scope | None (SAQ-A) | None (SAQ-A; iframe vault) | None (use Embedded Fields to tokenize cards) |
| Control over UI | Low | High | Highest |
| Time to integrate | ~30 min | ~half a day | ~1–2 days |
| 3DS | Automatic | SDK-managed modal | You handle next_action |
| Saved cards (buyer present) | Yes (via buyerId) | Token reuse in Checkout or Payment Intents | Yes |
| MIT (no buyer) | Not applicable | Token reuse in Payment Intents | Yes (recurring, retries, installments) |
| When to pick it | Simplest path; brand on checkout page acceptable | Brand control matters; standard one-page checkout | Delayed capture, fraud-check-before-capture, subscriptions, platform-integrator |
Checkout
The fastest path. Your server creates a session, the buyer pays on checkout.vonpay.com, and we redirect them back with a signed status. You write a redirect + a return handler — that's it.
Pick this if:
- You want the simplest integration that exists
- A Von-Payments-hosted checkout page is acceptable
- You don't need delayed capture or auth-only flows
Embedded Fields
Drop our iframe-vault fields into your own checkout page. The card form stays inside the iframe (PCI-isolated), but you control the page around it — branding, layout, copy. Cards tokenize to a vp_pmt_* you can charge via Payment Intents or use in a Session.
Pick this if:
- The checkout page brand has to be yours
- You want full control over page layout and copy
- One-page checkout is your target UX
Payment Intents
The server-side payment lifecycle API. Drive auth, capture, void, and refund as discrete steps. Used when there is no buyer-facing redirect and your server is the source of truth.
Pick this if:
- You need delayed capture (auth on order, capture on ship)
- You need a fraud check before capture
- You're building a platform, subscriptions, or recurring flows
- You need to drive auth, capture, void, and refund as discrete steps
Still not sure?
Need delayed capture, MIT, or recurring? ─────► Payment Intents
Need full UI control of the checkout page? ───► Embedded Fields
Just want the simplest thing that works? ─────► Checkout
Two paths often compose: Embedded Fields tokenizes the card, Payment Intents charges it. That's the standard recipe when you need both full UI control AND server-driven lifecycle (e.g. a SaaS that takes a card today and charges later).
Common to all three
- PCI scope. None on your side for Checkout and Embedded Fields. Payment Intents is PCI-out as long as you don't pass raw card data — use
vp_pmt_*tokens from Embedded Fields or an iframe-vault provider. - Webhooks. Same signed event surface —
session.*for hosted checkout,payment_intent.*for intents. See Webhooks. - AI agents. All three paths are agent-friendly via the same SDKs, CLI, and MCP server. See AI Agents.
- Test cards. The same sandbox cards work across all three. See Test cards.