Overview Introduction

• OVERVIEW
• STEPS FOR A SUCCESSFUL INTEGRATION
• DEVELOPMENT REQUIREMENTS

Overview

This document is a technical guide to describe the required and optional API functionality needed to integrate Cashier (“Cashier”) to your software platform (“Platform”).

Steps for a Successful Integration

1. Review this document in its entirety to acquaint yourself with the various integration points.
2. Schedule an introductory call between ourselves and your business stakeholders and IT developers to review the Cashier to Platform integration and discuss any special items or needs.
3. Review the business requirements as they relate to the integration between the Cashier and the Platform and how they can affect user experience or business processes.
4. We will setup the sandbox account and provide the credentials for you to start the development required for the sufficient communication based on your business needs (whether it's deposit only, deposit and payout, support for Backoffice and Virtual Terminal, etc.).
5. Build or expose an API for your Platform that serves the required functionality to integrate the Cashier to your Platform. This REST API should be built with security in mind, using your choice of programming language and accessory libraries.
6. Business stakeholders and developers can then review a fully working testing site integrated with your Platform and our Cashier, and coordinate the move to production once satisfied with the performance and work of both systems.
7. A Cashier training session will be scheduled prior to you going live. When you are ready to go live, you link your Platform cashier access to your new Cashier system. Our support team will be available for any issues or questions that may arise.
8. Once your production website is integrated with the Cashier (using Cashier live credentials), our support team will work with you to setup and configure your Cashier account, payment methods, limits, rules and more.

Development Requirements

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 approval rates.
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.