Server-side Cashier

Overview
Required steps
You need to pass three steps to form this widget: (1) get authorized as a merchant, (2) create a server session to generate a cashier token, and then (3) create a Cashier session to later let a shopper make a deposit. The first two steps are associated with two API methods; the other is a code launched in any HTML-supporting application (e.g. web browser).
1 Authorization
Get authorized as a merchant to establish a connection with the BridgerPay system by using the "POST Login" API method. The response will contain "access_token.token" (JWT token); use this value as a Bearer token when calling the following method.
2 Server session
A fresh token has to be created every time before the cashier is displayed to end user and not reuse a token.
Create a server session for BridgerPay's Cashier to generate a unique cashier token by using the "POST Create Server Session By Merchant API Key". Besides required session data, business data, and other input parameters, you will find there a shopper's personal and contact information. The more known pieces of this information you specify, the less the shopper will need to enter manually on the UI.
For information on how these input parameters will affect the behaviour or UI of a Cashier widget, see the "How they affect Cashier widget" tabs under Input parameters on the "Regular Cashier" page. In this case, you will need to pair the corresponding parameters with slightly different names, though, for example "data-first-name" and "first_name".
The response of this method will contain "cashier_token" encapsulating all the specified information on the shopper, following payment transaction, etc. This token may also encapsulate a "payload" parameter ensuring additional security. This all, compared to regular Cashier, will protect your sensitive data from intercepting and distorting.
3 Cashier session
Insert a code in any HTML-supporting application (e.g. web browser) to show the Cashier widget to a shopper. At this step, the server-side Cashier scheme can be integrated as a script embedded in your website or as an iframe placed in an arbitrary web resource. Depending on this choice, see the respective code example. The explanation of each parameter used is given later on this page. (Also mind the case style: it as well as the syntax varies.)
Code example
script [recommended]
iFrame
1
<!DOCTYPE html>
2
<html>
3
<body>
4
<script     src="https://cashier-sandbox.bridgerpay.dev/loader"
5
​
6
//session parameters (required)
7
​
8
data-cashier-key="{{CASHIER_KEY}}"
9
data-cashier-token="{{CASHIER_TOKEN}}"
10
​
11
//business restriction
12
​
13
data-direct-payment-method=""
14
data-single-payment-method=""
15
data-single-payment-provider=""
16
data-dont-skip-single-payment-box=""
17
​
18
//UI configuration
19
  
20
data-theme="light"
21
data-button-mode="modal"
22
data-button-text="Buy now"
23
        
24
>
25
</script>
26
</body>
27
</html>
Copied!
NOTE: Using this implementation requires redirection to be handled from your end using the Events​
1
<DOCTYPE html>
2
<html>
3
<body>
4
<iframe width=700px height=1000px src="https://cashier-sandbox.bridgerpay.dev/?
5
​
6
            cashierKey={{CASHIER_KEY}}&
7
            cashierToken={{CASHIER_TOKEN}}&
8
            singlePaymentMethod=credit_card&
9
            singlePaymentProvider&
10
            dontSkipSinglePaymentBox&
11
            alwaysVisibleInputsForProviders=%7B%22[field_name]%22%3A%5B%22[psp_name,psp_name2]%22%5D%7D
12
            theme=light"
13
​
14
            >
15
</body>
16
</html>
Copied!
Input parameters
You will find here the description of each parameter listed in the examples: its purpose, values that can be assigned if applicable, whether this parameter is required, etc. The parameters are logically grouped for your convenience, but in fact their order in the script doesn't matter.
Session parameters
data-cashier-key (required) — Software-level credentials that identify a merchant when creating a Cashier session; provided by BridgerPay
data-cashier-token (required) — Unique session identifier encapsulating information on a shopper, following payment transaction, etc previously specified when the server session was created
Since a cashier token is used, any attempt to "replace" data it encapsulates will be ignored. For example, you cannot modify the specified parameter of "currency_lock"='true' by adding a 'data-currency-lock'="false" line to the script.
Business restrictions
data-single-payment-method — Parameter making the shopper pay using a particular method (e.g. "credit_card" or "apm"). If specified, the step which the shopper could choose a method at is skipped, and the form of the "imposed" payment method is shown right away
data-single-payment-provider — Parameter making the shopper pay through a particular PSP (e.g. "zota_pay"). If specified, the step which the shopper could choose a method at is skipped, and the form of the "imposed" PSP is shown. Only this PSP will be requested to execute the payment transaction. Additionally, note that this parameter is not applicable to credit-card PSPs
data-dont-skip-single-payment-box — If a shopper is allowed to pay by using only one method, the step which this method can be chosen at is skipped. This parameter forces this step to appear ('true') so that the shopper will see the method and "choose" it. If not specified, 'false' is used by default
For information on how these input parameters affect the behaviour of the Cashier widget, see the "How they affect Cashier widget" tab under Business restrictions on the "Regular Cashier" page.
UI configuration
data-theme — Theme of the Cashier interface. The possible options are "dark" (used by default), "light", and "transparent"
data-button-mode, data-button-text — Cashier widget can be statically embedded in a merchant's website or can be invoked by clicking a relevant button. In the latter case, these parameters define the way this widget will appear and the name of this button, respectively. The possible options for "data-button-mode" are
"modal": the widget opens as a pop-up window
"tab": it opens in the active web page replacing the existing content, or in a new tab if the appropriate attribute of "_blank" has been added
"spot": it opens in the active web page but right below the invoking button as a separate module, without replacing the existing content

Solution - Previous

Regular Cashier

Next - Solution

Virtual Terminal

Last modified 2mo ago

Copy link

Contents

Business restrictions

UI configuration