Common Payment Flows
Use this page to choose the Zenith flow that best matches your implementation. Each flow below explains when to use it, what Zenith surface is involved, and where to go next for the full guide.
Payment Plugin Checkout Flow
Use this flow when you want Zenith to collect payment details in a hosted plugin experience and return the outcome to your system.
This is the lowest-friction path for one-off payments. Your server prepares the payment request, handles fingerprint generation and credentials, and receives the result through your callback handling. The payer completes the payment in the plugin, and your system validates the outcome using the callback, webhook, or a follow-up API check where needed.
Use this flow when:
- you want a hosted checkout rather than building card or bank account collection yourself
- you need a one-off payment flow with callback-based validation
- you want access to plugin-supported payment methods such as cards, bank flows, PayTo, or supported wallets
Related guides:
API Tokenised Payment Flow
Use this flow when you need to charge a stored payment method from your own application logic.
The common pattern is to first collect and tokenise the payment method, store the returned token safely in your system, and then create future payments by API using that token. This flow is suitable when your platform needs more control over timing, scheduling, retries, or customer account management.
Use this flow when:
- you need recurring or operator-initiated payments
- you want to link stored payment methods to a customer or internal entity in your system
- you need backend-controlled charging rather than payer-driven checkout each time
Operational notes:
- keep token storage and charge initiation on trusted backend systems
- track payment outcomes using API responses plus webhook or follow-up validation where relevant
- define your retry and reconciliation process before going live
Related guides:
Pre-Authorisation Payment Flow
Use this flow when you need to place a hold on funds first and capture or void that amount later.
Zenith's pre-authorisation workflow is a hybrid pattern. The payer enters card details through the Payment Plugin in pre-authorisation mode, your system stores the returned preauthReference, and later API calls are used to check status, capture funds, or void the hold.
Use this flow when:
- the final amount is confirmed after the initial authorisation step
- you need the ability to capture later or partially capture against an authorised amount
- your operational process requires an explicit hold-before-capture model
Related guides:
Batch Payment Flow
Use this flow when you need to process a group of payments as part of an operational run rather than one payer interaction at a time.
Batch-style workflows are typically driven from your backend or operations process. They are best suited to cases where your team prepares a defined set of payments, runs them through a controlled process, and then reconciles the results after the run completes.
Use this flow when:
- you process many payments as part of a scheduled or operator-managed run
- you need strong operational controls, logging, and reconciliation around the run
- your workflow is centered on back-office processing rather than individual payer checkout
Known limitation:
- this page only summarizes the flow shape; implementation details should be confirmed against the specific batch process you are using
Related guides:
Recurring Payment Flow
Use this flow when you need to debit a customer on a repeated schedule using a previously stored payment method.
Recurring payments usually start with tokenisation, followed by secure token storage in your system and scheduled backend API calls to create each new payment. Your implementation should also define how failed payments, retries, customer communication, and reconciliation are handled.
Use this flow when:
- you bill on a subscription, instalment, or scheduled-debit model
- you need to associate tokens with a customer, contract, booking, or account in your own system
- you want payment creation to happen from your backend on a defined schedule
Related guides:
Choosing the Right Flow
Use this quick guide if you are deciding where to start:
- Choose Payment Plugin Checkout when the payer is present and you want Zenith to host payment collection.
- Choose API Tokenised Payment when you need future backend-initiated charges using a stored payment method.
- Choose Pre-Authorisation when you need to hold funds first and capture or void later.
- Choose Batch Payment when your process is run-oriented and managed from operations or backend systems.
- Choose Recurring Payment when charges happen on a defined schedule.
If you are still deciding, start with Get Started and Best Practices, then move into the specific guide for your target workflow.