The API call you will make to complete a zip payment is a call to our <a href="/reference/au-loginwithzip-charges" class="codeLabel codeLabel-link" target="_blank" rel="nofollow noopener noreferrer">/charges</a> endpoint. This request is made once you wish to process payment using a customer access_token.
This API call will contain:
Customer access token (Bearer key passed as Authorisation header)
Your Zip private key (passed as X-Zip-API-Key header)
The Zip API response will contain:
Charge Id - a unique reference for your charge, to be used for refunds or cancel / capture flows
Receipt number - a unique <I>customer facing</I> reference for your charge. To be printed on receipts and is used in legacy 'in-store' refund scenario's.
This <span class="codeLabel codeLabel-nolink">/charges</span> API call should be made from your server and not directly from the client front end. <br>
## Customer access token
This will have already been obtained in the create token or refresh token Api calls. This should be passed as a Bearer Authorisation header in the POST /charges request. e.g.
## Your Zip private key
Zip require your merchant private API key to be passed in the /charges request header. e.g.
## Order info
Zip also require details of the order to be passed in the checkouts request, including:
Here is an examples of how this information can be passed:
## Capture flag
When a charge is made, it must be specified if the funds should be immediately captured or only authorised. In most cases merchants will use immediate capture. This can be passed to Zip as below:
## The full request
An example payload can be found below:
With a successful response from Zip, you have now completed your charge! <br>
If you have completed your charge with the capture flag set to false, you will still need to [capture or cancel the charge](🔗).
Additionally, implementing [refunds](🔗) is advised, but not required
Next its time to review your [go live requirements](🔗)