...
This document is designed to offer advise on how to set up and advise Integrators on how to use Head Office level payers .Further details on API calls listed in this documentation, as well as error codes, examples responses and models can he found herevia API.
...
USAGE
Head Office Mode allows an integration to add payers to a Head Office account. These payers can then have transactions scheduled against them regardless of what Business the payer sits in.
The transaction is linked to a business but is processed under the Head Office business. This removes the requirement for a Payer to exist in both businesses, it can just be called form from the Head Office.
A use case for this would be a Gym membership.
The Payer is a member or of Gym A, the Scheduled monthly payment is transacting at Gym A.
But today is working out at Gym B, the Payer purchases a water bottle at Gym B.
As the Payer has HO detailsexists in the Head Office account, the purchase of the water bottle can be a saved card details transaction against the details saved at HO. With Head Office account level with the transaction registered against the Sub Business.
...
Head Office mode allows for use of a single set of API credentials to access multiple Sub Businesses. When authorizing authorising a request these must be used as below:
...
When processing a real time card payment that needs to be linked to a Sub Business you can use Head Office details for the login, as previously mentioned, and provide the Sub Business ID in the URL of the request.
| Info |
|---|
Note - you will need to use the Business Key of Sub Business to tokenise card |
{{url}}/businesses/{{Sub Business-Id}}/transactions/card-payments
...