Solution map

This page shows you the big picture of BridgerPay's offer and, hopefully, answers your fundamental questions, no matter who you are: a decision maker, developer, or integration engineer.

Embed vs. API
We offer you two solutions, which, depending on your case, can be employed separately or together. One, Embed (see the following figure), is a Cashier widget: a front-end solution embedded in your website ("script") or located in an arbitrary web resource ("iframe"). It allows your online customers—shoppers—to enter their personal, contact, and business information, confirm a purchase, and see the status of their payment (deposit).
The other, API, is a set of REST API methods.They can be roughly divided into two groups. The methods belonging to a first group are used to organize the payment process, i.e. accept shoppers' transactions. The Cashier widget is based on them (see "Cashier initialization" and "Payments" in the following figure); and you too can utilize them to connect your own front-end part if, for any reason, our Embed solution is not suitable for your business (see "MPI"). The methods belonging to the other group are intended for "after-payment" services: refunds and payouts.
BridgerPay's solutions
Regular Cashier vs. server-side Cashier
If you choose to employ our Cashier widget, you have two alternatives (schemes) to do this: regular Cashier or server-side Cashier. The former is simpler and consists of only one step; the other, of three steps. Each step is associated with one API method (see the blue-green "plumes" in the preceding figure). Some of these methods are "under hood" (drawn in grey): we don't provide access to them, and you use them indirectly. The others are called manually, and thus you need credentials to work with both Embed and API.
When integrating the regular Cashier scheme, you launch a JS code with your cashier key, provided by BridgerPay, and other parameters to create a Cashier session for further deposits. It doesn't demand access to the API methods.
When integrating the server-side Cashier scheme, you need to log in to the BridgerPay system (step 1) to generate a server-side (cashier) token (step 2), which will encapsulate all the information for creating a more secure Cashier session. (To do this, you call the respective API methods.) And only after that, similar to integrating the regular Cashier, you launch a JS code with the cashier key and cashier token (step 3).
Upon integration, shoppers interact with a Cashier widget: they select a payment method, enter their information, confirm a purchase, see the result of their deposit, etc. These activities are enabled by "under-hood" Payment API methods. We don't provide direct access to them but show them in the solution diagram (drawn in grey) to give you a better understanding of our architecture.
API methods
Our API methods are grouped according to their purpose. You see all of them in the preceding figure, and we are working on providing you with a wider choice. For now, these are:
​Authorization to log in to the BridgerPay system
​Cashier initialization to create a Cashier and server sessions to later accept a shopper's deposit
​Payments to accept a shopper's deposit via a Cashier widget and get the current status of a payment transaction
​MPI (Merchant API) to accept a shopper's deposit via your own front-end solution, alternative to a Cashier widget, and get the current status of a payment transaction
​Refunds to initiate a partial or full refund for a shopper
​Payouts to transfer funds you owe a shopper according to your mutual agreement: insurance compensation, prize, etc. The methods grouped here also provide additional relevant functionality: getting a list of available PSPs, getting the current status of a payout transaction, and so on.
Q: What's the difference between the server-side Cashier scheme and MPI methods?
A: The server-side Cashier scheme implies that you provide some known information on a shopper and their transaction, e.g. the first and last names and other data based on the profile, and the purchase price. After that, the shopper enters the missing and business information, e.g. the credit card credentials, by using our Cashier widget.
The MPI methods are about server-to-server deposits. You collect all the information of a shopper, including the credit card credentials, by using your own front-end solution, and then transmit it. Additionally, this approach supports only the debit and credit card payment methods.
(You can always find the answer to this and other popular questions in our FAQ.)
Who are involved
There are four parties involved in BridgerPay's business processes: your customer (shopper), you (merchant), BridgerPay, and PSPs. Additionally, a Cashier widget, if applicable, can be included in this set too (see the following figure). All the parties communicate with each other to reach a particular business goal: successfully make a deposit, return funds, etc. If these communication processes are complicated and engage various methods, they are detailed on the devoted pages, for example the Overview of MPI.
Involved parties
BridgerPay also informs you of changes to the statuses of key operations by means of the system of notifications.

How to read this documentation

Next - Get started

Reference book

Last modified 1yr ago

Copy link

Outline

Embed vs. API

Regular Cashier vs. server-side Cashier

API methods

Who are involved