Skip to main content
This page is part of the REST API Guides. Card capture happens in the frontend through the Payments Library; see the Payments Library Guides.
Prerequisites: API key, a Payment Gateway Account, and a payment schedule template configured in the Orchestra portal. Payment contracts are how you charge a card more than once from a single customer interaction. They cover instalment plans, subscriptions, monthly billing, membership renewals and any other arrangement where one agreement produces a series of payments. You capture and tokenize the card once, create a contract, and Orchestra runs the payments on the schedule. Because the schedule is tied to a payment gateway account rather than to one processor’s own subscription product, moving a plan between processors is a configuration change, not a rewrite of your billing code.

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:
If you took the first payment with CHARGE_AND_TOKENIZE, set startDate to the date of the second payment and count only the remaining payments in maxOccurrences. The contract does not know about the charge you already took.
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, set maxOccurrences, 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

Because maxOccurrences 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.
Each instalment is charged to the card when it falls due, so the card must still be valid and funded on each date. The full amount is not reserved up front. For long plans, watch for cards expiring mid-plan and collect a replacement before the next payment.

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:
  • endDate stops payments after a calendar date.
  • maxOccurrences stops payments after that many successful charges.
Set both and whichever is reached first ends the contract, which then moves to Completed on its own.
For a fixed instalment plan use maxOccurrences rather than endDate. It counts successful payments, so a payment that fails and is retried does not cut the plan short.

Timezones

Two optional fields control which day a payment lands on:
  • merchantTimezone
  • cardholderTimezone
Both take IANA names, for example 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

Cancelling is permanent. A cancelled contract cannot be resumed, and recovering the arrangement means creating a new one. Use pause for anything temporary, such as a payment holiday or an account under review.
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.