This document is a technical guide to describe the required and optional API functionality needed to integrate Cashier (“Cashier”) to your software platform (“Platform”).
In order to efficiently proceed with the technical part, first you will need to make sure that you have the understanding of certain functional aspects, that eventually define the scope of development as well as the technical and formal requirements.
Cashier API or Payment API. In case of Payment API please make sure that the PCI L1 compliance documents (AOC) are provided by you or your CRM software provider. Alternatively, please refer to Cashier API integration.
Support for payout - yes or no. If yes, we need to have the full Backoffice integration implemented and tested. Also, make sure to enlist all the PSPs that you are planning to use for payouts.
Using the payout management API - yes or no. When processing a payout request, you can either use Backoffice or Agent API. Please make sure to notify us which option is preferred before getting to confirm the list of PSPs to be used.
Authorization & capture - yes or no. If yes, please make sure to confirm with us on each PSP whether it supports authorization & capture, and confirm if this is the flow you are planning to use.
Using the deposit management API. when it comes to capture upon the authorized deposit, you have two options to go with - using Backoffice or via Agent API. Make sure to specify which one you are planning to use.
Support for Backoffice & MOTO (manual deposits on behalf of the customer) transactions - yes or no. If yes, the customer sync as well as the manual ("offline") deposit notifications should be supported by your CRM software.
Using the fixed deposit amount or free deposit. Fixed deposit can be referred to as e-commerce checkout, where the
deposit must match the amount of the order previously generated with your CRM or website. This approach gives you more
control over the process, however, it applies some restrictions on the customer's actions, which may result with lower
Alternatively, if you are not restricting the customer to pay a specific amount, this gives the higher rates but at the same time you can only validate the deposit attempt without being able to influence the customer's preference
before it's submitted for validation.
Using the fixed payout amount or free payout request. Similar to deposits, the payout requests may be initiated with a predefined amount that customer will not be able to change. It's up to you to choose which option works for you best, but if you are not sure about this, better to keep the payout requests having the open amount, so the customer will specify it as a part of the payout request submission process.
You are currently viewing version 3.4 Latest version here