Overview Migrating from earlier API

---

• DEFINITIONS
• REST API NOTIFICATIONS
• CASHIER LOGIN
• NEW SERVICE MAPPING
• GLOSSARY

Definitions

Terms

Products affected: software public API of versions 1.0, 0.24 and lower notifications.
Deprecation start: Monday, November 11th, 2019
Discontinuation date: Monday, February 3rd, 2020

Scope

API is the interface established between your CRM and Praxis, including the login, deposit and payout notifications, customer pull and push, balance sync.

Deprecation

The earlier API versions will no longer receive the new features and performance updates, the online documentation will be moved to archive and will not be maintained further.

Discontinuation

When the earlier API versions are discontinued, any CRM that is identified in by the API version prior to 1.1, will be treated as inactive. An inactive platform cannot send the requests to API nor receive the notifications back.

Migration

In the context of a present document, the migration is a sequence of activities between the merchant’s development team representatives and technical support, including the API introduction call, definition of features to be implemented, sandbox environment configuration, development, testing and production environment update.

Data consistency

Processing data, customer data, PSP configuration, scrubber configuration, limits, Cashier layout (except Cashier menu, see Cashier Login), Backoffice accounts and frontend names remain unchanged.

REST API Notifications

The API interfaces from the versions up to 0.24 have a different scheme and naming. Below is a quick reference of the method correspondence when migrating to API version 1.1:

• AuthCust - no longer used
• GetCustomer - customer sync now expects for the customer details as well as the current balance
• PrevalidateDeposit - validation is a universal call triggered for both deposit attempt and payout request, but will be omitted for {init-checkout}
• PendingDeposit - notification, refer to transaction_type:deposit and status:pending in order to indicate the transaction being initiated in or changing to pending status
• AuthorizedDeposit - notification, refer to transaction_type:deposit and status:authorized in order to indicate the transaction being changed to authorized status. Please note that the transaction status will not change for the time frame defined by PSP until the capture is triggered manually within Backoffice or via {deposit-capture} API call
• ProcessDeposit - notification, refer to transaction_type:deposit and status:approved as indication of final approved status
• RecordFailedDeposit - notification, refer to transaction_type:deposit and status:declined as indication of final declined status
• RecordChargeBack - notification, refer to transaction_type:deposit and status:chargeback as indication of final chargeback status
• ReverseDeposit - notification, refer to transaction_type:deposit and status:reversed in order to record the deposit reverse (cancellation) transaction related to a preceding approved deposit
• CreatePayout - validation is a universal call triggered for both deposit attempt and payout request, but will be omitted for {init-pay-out-order}
• UpdatePayout - notification, refer to transaction_type:payout and one of status:requested|authorized|in progress|approved|rejected|reversed in order to handle the payout request status change upon being requested
• ReversePayout - notification, refer to transaction_type:payout and status:reversed in order to record the payout reverse (cancellation)

Cashier Login

The Cashier login for earlier integrations was achieved by submitting the hidden login form to https://cashier.praxispay.com/Login.asp, whereas the new login is done via API, similar to average paywall or e-wallet login implementation:

1. Call to init method (see below) - redirect_url is returned in response
2. Open the received redirect_url for customer (by setting the return_url as value of <iframe src="..."> attribute of value), no extra page with form required

With the earlier integrations there was an option to pass the Cashier action within the login form as well as letting the customer choose between “Deposit” and “Payout” using the Cashier top menu. Now the top menu is deprecated, whereas the action is defined per init request. There are four Cashier flow options available:

• {init-pay-in} - regular deposit, works best if you used to have the Cashier login form without SCI(?)
• {init-checkout} - deposit with predefined amount, this method should be used as a replacement to the deposit login form with SCI(?) enabled (where SCOrderID and SCAmount were provided within the Cashier login form)
• {init-pay-out} - regular payout, the customer defines the payout amount within the Cashier, should be used as a replacement for the regular payout flow (where Action=PAYOUT appeared in the Cashier login form)
• {init-pay-out-order} - a new flow, the customer is logged in to Cashier to make a payout request having the amount read-only (passed from the website within the init method call)

New Service Mapping

Cashier API

Cashier API provides the API methods for Cashier login and defines the corresponding notifications. If you are using the earlier API version, then most probably your migration will start with the Cashier API integration.

Agent API

Agent API is a set of REST API methods designated to execute the backoffice(?) operations via API, including the deposit management, payout management and transaction lookup.

Payment API

Payment API, also referred to gateway integration interface is a REST API to perform the transactions. Considering that the gateway API expects to receive the card data to be collected on the merchant side, this integration requires the merchant’s PCI DSS L1(?) compliance.

Glossary

Backoffice and VT

Backoffice and Virtual Terminal are the admin interfaces provided by as complementary to the Cashier. Using the Backoffice you can manage the customers' profiles as they are reflected upon sync between your CRM and Praxis, perform the deposits and payouts on behalf of the customer and configure the Cashier as well as the payment methods and the way they are presented to customers.

SCI

SCI is an acronym for Shopping Card Interface, this is a frontend configuration option that enables the Cashier interface meant to accept the payment for the amount that is specified by the website (CRM) via an additional paratemer within the Cashier login form.

PCI DSS

PCI DSS stands for Payment Card Industry Data Security Standard. PCI DSS has a definition and criterias for the security standards required in order for the merchant to provide the online payment services, while having the sufficient security level for the service itself and it's end-users (clients doing the payments).