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 Praxis 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 relates 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 moving to production if satisfied with the performance and work of both systems.
7. Once your production website has been setup with the Cashier integrated using the live Cashier credentials, our support team will work with you to setup and configure your Cashier account, payment methods, limits, rules and more.
8. 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.

Development Requirements

In order to efficinently proceed with the technical part, first you will need to make sure that you have the understanding for certain functional aspects, that eventually define the scope of development as well as the technical and formal requiremetns.

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 Praxis 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 has a support for authorization & capture, and confirm if this is the flow you are planning to use with.

Using the deposit management API. when it comes to capture upon the authorized deposit, you have two options to go with - using Praxis Backoffice or via Agent API. Make sure to specify which one you are planning to use.

Support for Backoffice & MOTO 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.