This is the fastest way to get started using the virtual card offering from Sezzle. A virtual card checkout implements the Card Session API to provide an easy to use, in-context solution for issuing and using a Sezzle virtual card as payment.
The Sezzle non-production environment does not provide a way to test the payment processing using your provider.
The origin domain needs to be allowlisted by Sezzle for Virtual Card SDK to function. Please contact your Account Manager and they can do this for you.
Checkouts
Virtual Card Checkout in an iframe or pop-up window.
Card Details
Enable plain card details through message event or tokenization.
Payments
Handle payment success, failure, or cancel with your virtual card orders.
If you use iframe mode, add *.sezzle.com to your site’s Content Security Policy (CSP) allowlist so the Sezzle checkout iframe can load.
popup (recommended): works out of the box for most browser-based SDK integrations.
iframe: required when popups are blocked (e.g. inside a webview or embedded browser). Sezzle must enable iframe for your domain(s) first — submit your Merchant UUID and the domains to allow per environment (sandbox and production). For example: please enable uat1.mysite.com, uat2.mysite.com in sandbox and www.mysite.com, mysite.com in production.
redirect: supported but generally less useful with the SDK, since the SDK’s value is the in-context checkout and window messaging.
Place the element snippet from the Template tab where you wish the Sezzle Button to be rendered on the page, then update the Options attributes as needed.
Add the following function to render the button when it is appropriate, such as when payment methods section loads, or when Sezzle is selected as a payment method. The parameter corresponds to the element created in the previous step.
The SDK uses these event handlers to tell your site what’s happening in the checkout. Implement each one to react to shopper actions like completing, cancelling, or running into an error.
Template
Example
Options
checkoutSdk.init({ onClick: function () { event.preventDefault(); checkoutSdk.startCheckout({...}); }, onComplete: function (response) { console.log(response.data); }, onCancel: function () { console.log("Checkout cancelled."); }, onFailure: function () { console.log("Checkout failed."); },});
checkoutSdk.init({ onClick: function () { event.preventDefault(); checkoutSdk.startCheckout({ checkout_payload: { amount_in_cents: 1000, currency: "USD", merchant_reference_id: "merchant-checkout-id-max-255", customer: { email: "test@test.com", first_name: "John", last_name: "Doe", phone: "0987654321", billing_address_street1: "3432 Terry Lane", billing_address_street2: "12", billing_address_city: "Katy", billing_address_state: "TX", billing_address_postal_code: "77449", billing_address_country_code: "US", }, items: [ { name: "Blue tee", sku: "sku123456", quantity: 1, price: { amount_in_cents: 1000, currency: "USD", }, }, ], }, }); },onComplete: function (response) { // Virtual card data is available in response.data.card and response.data.holder. // Use this data to charge the card through your own payment processor // (e.g., Stripe, Cybersource, Braintree). console.log("Card data received:", response.data); }, onCancel: function () { console.log("Checkout cancelled."); }, onFailure: function () { console.log("Checkout failed."); },});
checkout_payload is optional but providing as much information as possible will improve customer experience.
The checkout_payload schema mirrors the Create a card session request body. See that reference document for the full list of fields, types, and constraints - including card_response_format.
merchant_reference_id is used only for troubleshooting. The Reference ID that shows in the Merchant Dashboard can be set using Set Order Reference ID.
This response format delivers the full card number (PAN) and CVV directly to your frontend JavaScript. If your systems do not already handle raw cardholder data, this may expand your PCI DSS compliance scope. For a more secure alternative, see onComplete with tokenization, which keeps card data out of the browser and limits handling to your server.
The event.data will contain a fully formed payload containing the customers payment method. This information is not the payment method used to pay Sezzle but one that can be used through your payment gateway (Cybersource, Stripe, Braintree, etc).
Recommended for most merchants. Tokenization keeps card data out of your browser and reduces your PCI DSS compliance scope. Card data is retrieved server-side only.
Tokenization is a feature developed for merchants who do not want the card information sent directly through the message event. Instead the payload to onComplete will contain a card token string, which your server can exchange for card data using the Virtual Card Data API. The token is single-use and expires after 24 hours.
In many cases, the merchant order ID will not be generated until after the checkout is completed and an order is created. Call setOrderReferenceID to set the Sezzle Order Reference ID with the merchant order ID after the virtual card transaction has been successfully completed.