Glossary

Bridger Merchant Admin Portal (or Merchant Admin) — A web system BridgerPay provides a merchant with upon signing the contract. It is used to manage all the payment processes of this merchant, from selecting and ordering PSPs to viewing the details of each transaction.

Bridger Router — BridgerPay's solution used to associate a merchant with various PSPs operating in different countries and supporting different payment methods and currencies. You can define there the sequence which these PSPs will be requested (tried) to execute a transaction in if two or more appropriate PSPs are available. You can also choose which PSPs to work with and which to ignore (disable), and more. See also "Retry".

Capture — The process of transferring a shopper's reserved funds to a merchant's account. See also "Payment".

Cashier initialization — The process of creating a Cashier session to later make a payment transaction (e.g. to deposit). There are two ways to do this by using BridgerPay's methods: simple and more secure. One is to specify information on a shopper, following payment transaction, etc and straightly create a Cashier session. The other is to generate a server-side (cashier) token encapsulating this information and then transmit this token to create a Cashier session.

Merchant — A b2b client of BridgerPay, which can be any commercial organization accepting payments from its b2b or b2c clients: a broker, insurance company, Internet shop, etc. This is one of four parties involved in BridgerPay's business processes; the other three are PSPs, BridgerPay, and shoppers.

Payment — Funds that a shopper transfers to a merchant for goods or services provided. For some payment methods (e.g. debit and credit cards), a payment operation is performed in two phases: "pre-auth" (authorization) and "capture". At the former, the payment details of the shopper are verified, and the funds are reserved, while at capturing the reserved funds are transferred to the merchant's account. These phases commonly pass together, one immediately after the other. But some PSPs allow you to capture a payment later, for example, after the deal has been confirmed or the goods have been shipped. This, in case of any issue, will let you avoid the bank transfer commission since already captured payments can be only refunded.

Payout — Funds transferred by a merchant to a shopper according to their mutual agreement: insurance compensation, prize, etc. Unlike a refund or chargeback, this transaction is not associated with any previous transaction, and thus neither PSP nor BridgePay has information on the amount to be transferred. It is initiated by the merchant, and the shopper is not involved in the process.

Pre-auth (or "payment authorization") — The process of verifying the payment details of a shopper and later reserving the funds. See also "Payment".

Refund — Funds transferred back to shoppers, especially if they have paid too much for the goods or services (partial refund) or are not satisfied with the quality (full refund).

Retry — A mechanism allowing a merchant to receive a payment by trying two or more appropriate PSPs according to their sequence in this merchant's Bridger Route. The PSPs are tried one after another until the payment transaction is accepted by one or declined by all available PSPs. For example, a shopper is making a deposit into the merchant's account with a credit card in EUR in Belgium. Two PSPs supporting this currency/country combination are available to the merchant: "PSP1" (first according to the Bridger Route) and "PSP2" (second). The "PSP1" is tried first. If the transaction is accepted, both parties—the shopper and merchant—are informed about it. if not, the following PSP ("PSP2") is tried.

Shopper — A b2b or b2c client of a merchant, i.e. a company or individual that consumes products or services provided by the merchant. This is one of four parties involved in BridgerPay's business processes; the other three are PSPs, BridgerPay, and merchants.

Webhook — A feature aimed to develop push notifications, HTTP posts, triggered by some actions, for example, when the status of a transaction has changed. BridgerPay's notifications have JSON format; we configure them for you to be sent to a predefined resource.