Glossary

You will find here the explanation of some financial and BridgerPay-specific terms you may not be familiar with.

Term
Description
Bridger Merchant Admin Portal (or Merchant Admin)
The web system BridgerPay provides a merchant upon contract signing. It is used to manage all the payment operations, from selecting and managing PSPs to viewing and reporting on the details of each transaction.
Bridger Router
BridgerPay's solution used to connect various PSPs to a merchant's checkout. Each route can contain PSPs that are optimal for a specific country or region. The Router is used to define the fallback sequences for credit card providers (Bridger Retry™). You can also set Rules to choose which PSPs to work with and which to ignore (disable) in specific situations (see Rules).
Pre-auth (or "payment authorization")
The process of verifying the payment details of a customer and later reserving the funds. See also "Payment".
Capture 
The process of transferring a customer's reserved funds to a merchant's account. See also "Payment".
Void 
The process of releasing the funds that were on hold back in the cardholder's account.
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: simple and more secure. The first one creates the Cashier session immediately after the customer has input their information, and the second is to generate a server-side (cashier) token that encapsulates all the information and then use the token to create a Cashier session.
Merchant 
A client of BridgerPay that accepts digital payments. This is one of four parties involved in BridgerPay's business processes. The other three are PSPs, BridgerPay, and customers.
Customer
A client of the 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.
Payment 
Funds that a customer transfers to a merchant for the goods or services they want to purchase. 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 customer are verified, and the funds are reserved, while at capturing the reserved funds are transferred to the merchant's account. Some PSPs allow you to capture a payment later, for example, after the deal has been confirmed or the goods have been shipped.
Payout
Funds transferred by a merchant to a customer 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 customer is not involved in the process.
Refund 
Funds transferred back to customers. Refunds can be full or partial.
Bridger Retry™
A technology allowing a merchant to rescue a card payment declined for technical reasons. When the payment is declined by the first PSP, it is submitted in real-time to the next PSP in the sequence (established in the Route). For example, a customer 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 customer and merchant—are informed about it. if not, the following PSP ("PSP2") is tried.
Webhook 
A feature that creates push notifications (HTTP posts) triggered by some action, for example, when the status of a transaction changes. BridgerPay's notifications have JSON format. BridgerPay configures them for you to be sent to a predefined resource.

Term	Description
Bridger Merchant Admin Portal (or Merchant Admin)	The web system BridgerPay provides a merchant upon contract signing. It is used to manage all the payment operations, from selecting and managing PSPs to viewing and reporting on the details of each transaction.
Bridger Router	BridgerPay's solution used to connect various PSPs to a merchant's checkout. Each route can contain PSPs that are optimal for a specific country or region. The Router is used to define the fallback sequences for credit card providers (Bridger Retry™). You can also set Rules to choose which PSPs to work with and which to ignore (disable) in specific situations (see Rules).
Pre-auth (or "payment authorization")	The process of verifying the payment details of a customer and later reserving the funds. See also "Payment".
Capture	The process of transferring a customer's reserved funds to a merchant's account. See also "Payment".
Void	The process of releasing the funds that were on hold back in the cardholder's account.
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: simple and more secure. The first one creates the Cashier session immediately after the customer has input their information, and the second is to generate a server-side (cashier) token that encapsulates all the information and then use the token to create a Cashier session.
Merchant	A client of BridgerPay that accepts digital payments. This is one of four parties involved in BridgerPay's business processes. The other three are PSPs, BridgerPay, and customers.
Customer	A client of the 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.
Payment	Funds that a customer transfers to a merchant for the goods or services they want to purchase. 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 customer are verified, and the funds are reserved, while at capturing the reserved funds are transferred to the merchant's account. Some PSPs allow you to capture a payment later, for example, after the deal has been confirmed or the goods have been shipped.
Payout	Funds transferred by a merchant to a customer 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 customer is not involved in the process.
Refund	Funds transferred back to customers. Refunds can be full or partial.
Bridger Retry™	A technology allowing a merchant to rescue a card payment declined for technical reasons. When the payment is declined by the first PSP, it is submitted in real-time to the next PSP in the sequence (established in the Route). For example, a customer 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 customer and merchant—are informed about it. if not, the following PSP ("PSP2") is tried.
Webhook	A feature that creates push notifications (HTTP posts) triggered by some action, for example, when the status of a transaction changes. BridgerPay's notifications have JSON format. BridgerPay configures them for you to be sent to a predefined resource.

Introduction to BridgerPay

Reference Book

Last modified 6mo ago