Zepto Flow is an embeddable PayTo experience for your own checkout. You create a Payment Intent with a single API call from your server, then you hand the result to the widget in the payer's browser. From there the widget does the work: it collects the payer's account details, it waits while the payer approves the PayTo agreement in the banking app, then it tells your page the outcome.

You get a PayTo integration, without having to build the UI or manage multiple calls to Zepto's APIs. The payer's payment details never touch your servers.

What is a Payment Intent?

A Payment Intent is a server-side object that represents one checkout session. It holds the agreement and the payment you want to take, and it drives the widget from start to finish.

You create a Payment Intent on your server with your secret API key. In return you get a browser-safe token and the first action. Pass both to your page.

A Payment Intent has four traits worth knowing:

• One per checkout. It covers a single session: one PayTo agreement and one payment. Create a new Payment Intent for each checkout attempt.
• Temporary. It is short-lived. The token is scoped to this one Payment Intent, and it cannot be reused across sessions.
• Client-side safe. The token is the only credential that reaches the browser. Your secret API key is only used between your server and our API.
• Self-driving. After the widget is mounted with the token and action, the Payment Intent advances through the workflow until it settles or fails.

You create it in the first step. See Create a Payment Intent for the full request.

How it works

Flow splits cleanly into two responsibilities.

Your backend makes one server-to-server call to create a Payment Intent. It uses your secret API key for authentication. It gets back a token and the first action.

Your checkout page loads the Flow SDK. It mounts the widget with that { token, action }. Then it listens for lifecycle events. The widget makes every later API call with the browser-safe token for authentication - your secret key isn't needed.

The end-to-end sequence:

1. Your backend calls create-payment-intent and receives { token, action }.
2. Your page mounts the widget: ZeptoFlow.mount('#el', { token, action }).
3. The widget collects the payer's PayID or BSB and account number. Then it creates the PayTo agreement.
4. The payer approves the agreement in the banking app. The widget waits.
5. The widget creates the payment and waits for settlement.
6. The widget emits a terminal event: zepto:payto:payment-settled or zepto:payto:payment-failed.

What Flow supports today

Flow now supports the one-time payment flow (PayTo.Debtor.OneTimePayment). It creates an agreement and takes one payment against it in one guided session. We will add more flows to this guide when they become available.

Flow is built to grow beyond PayTo. Events are namespaced by rail (zepto:payto:*), which leaves room for future rails such as PayID (zepto:payid:*).

Build it in five pages

This guide shows you a complete integration:

1. Before you begin: API keys, environments, and how to load the SDK.
2. Create a Payment Intent: the one server-side call.
3. Mount the widget: add Flow to your checkout page.
4. Handle the payment lifecycle: react to the events.
5. Test in the sandbox: check the success and failure paths.

For theming, see Theming the widget. For the complete client API, see the SDK reference.