This page is part of the REST API Guides. Card capture happens in the frontend through the Payments Library; see the Payments Library Guides.
The Three Pieces
One template normally backs many contracts. That is what keeps every customer on the same plan billing identically.
End-to-End Setup
1
Create the template in the portal
Once per plan. Choose the frequency (Daily, Weekly, BiWeekly, Monthly, Quarterly, SemiAnnually or Annually) and the payment gateway account that will process the payments. Note the template id.
2
Collect the card and get a token
Start an eWallet session and let the customer pay or enter their card in the frontend. The operation you choose decides whether the first payment happens now:See the Payments Library setup guide for rendering the payment sheet in your page.
3
Read the token from the result
When the session completes, validate the results and take the token:The response carries
tokenAndMaskedCardModel, whose token field is what the contract needs. The same object holds the masked card details, which you can store to show the customer which card their plan is billed to.4
Create the contract
Tie the template and the token together:
5
Store the contract id
You need it to retrieve, update, pause, resume or cancel the arrangement later.
templateId, name, tokenId, startDate and chargeRequestData are required. Everything else is optional.
Instalment Plans
An instalment plan is a contract with a fixed number of payments. Divide the total by the number of instalments, setmaxOccurrences, and use a template with the right frequency.
For a 600.00 purchase split into 5 monthly instalments, against a template whose frequency is Monthly:
Offering a Choice of Plans
BecausemaxOccurrences and amount are set per contract, you can decide the number of instalments at the moment of purchase. A checkout that offers one immediate payment, up to 5 instalments, or up to 18 instalments needs no configuration per event: your page presents the options, and you create the contract that matches what the customer chose.
The maximum you allow is yours to decide and can differ per product, per event or per page. Nothing in Orchestra caps it.
Frequency comes from the template, not from the contract. If you offer monthly and weekly plans, create one template per frequency and point each contract at the right one. The number of payments and the amount stay per contract.
Charge Data
chargeRequestData describes the payment made each time the schedule fires:
Some processors require additional parameters, and some treat recurring payments differently from one-off ones. Check Additional Guidance for your processor before going live with a plan.
Deciding When Payments Stop
A contract can run indefinitely, or you can bound it:endDatestops payments after a calendar date.maxOccurrencesstops payments after that many successful charges.
Timezones
Two optional fields control which day a payment lands on:merchantTimezonecardholderTimezone
America/New_York. Leave them out and Orchestra applies its defaults. Set them when a monthly charge should fall on the first of the month in the customer’s timezone rather than yours.
Managing a Running Contract
To change the amount, the currency or the card, cancel the contract and create a new one. Those are fixed for the life of a contract, which keeps the billing history unambiguous.
Tracking Progress
Listing supports filtering by
templateId and status, with pageNumber and pageSize for paging. Filter by template to see everyone on a plan, by status to find contracts that are paused and should not be.
Next Steps
Payment Contracts API
Full reference for every contract endpoint.
Payments Library Setup
Collect the card and create the token in your frontend.
Gateway Requirements
Processor-specific parameters to check before you schedule.
Transaction Status
Check the outcome of individual payments.