Introduction

Key Definitions

Some useful definitions for key terminology used throughout the integration documentation.

BR-DGE & Comcarde

Comcarde is our company name, and we initially developed BR-DGE with the same name. We are now rolling out the BR-DGE product name, but you will still see Comcarde used in domain and SDK names until the re-branding process is complete.

Merchant Account

You can have one or more accounts with us, each tailored to a specific use case you may have.

An account defines things such as:

• The Payment Service Provider accounts you wish to use.
• The rules for routing your payment.
• The currencies you wish to support.
• Which payment instruments and other features you have enabled.

Payment

Represents a request to transfer funds between accounts at banks or other financial institutions.

Payment Service Provider

A Payment Service Provider (PSP) offers merchants online services for accepting electronic payments by a variety of payment methods (payment instruments).

PSPs process payments via connections to acquiring banks and payment networks.

Payment Instrument

Electronic instrument with which end users of payment systems transfer funds between accounts at banks or other financial institutions.

3-D Secure

3-D Secure provides an additional layer of cardholder authentication when making electronic payments. Cardholders benefit from reduced risk of fraudulent activity on their account, and merchants benefit from fewer fraud related chargebacks.

The original implementation (3-D Secure 1.0) added an extra layer of friction to the payment process, so to address these concerns 3-D Secure 2.0 was created, which introduced a frictionless flow and integrates better with smart devices for a smoother overall experience.

3-D Secure 2.0 satisfies the Strong Customer Authentication (SCA) requirements coming into effect for European merchants transacting with European customers.

API Keys

You can generate API keys in the BR-DGE Portal.

The keys will be specific to a Merchant Account, Environment (Sandbox/Production) , and grouped into two main classes based on how they will be used.

• Server API Keys must only be used in your server, and never exposed to your client applications.
• Client API Keys will be provided for use in client applications to support features such as BR-DGE Hosted Fields, Drop-In UI, 3-D Secure, etc.

👍

We recommend you don't embed API Keys in source code or binaries, as this is a security risk, and will make it harder for you to update your keys should we need to issue new ones.

Payment Flows

Payments using BR-DGE can be grouped into the following main flows. All payment flows involve the use of your Server API Key to ensure there are no unauthorized payments.

Alternatively, you can fully outsource your payment page to BR-DGE using our customizable Hosted Payment Page, which has its own flow.

Tokenized Payment Flow

Fully outsource all your cardholder data functions to BR-DGE so that your platform qualifies for the simplest SAQ-A PCI Compliance Form level. In addition to cards, this flow also supports many digital wallet payment instruments such as Apple Pay, Google Pay^TM, and PayPal.

1. Your server sends a Client API Key to your client (1).
2. BR-DGE PCI-DSS SAQ-D compliant Web SDK and systems collect payment data and generate tokens that can be safely handled by your PCI-DSS SAQ-A platform.
3. Your client sends the payment token to your server, along with checkout information (3).
4. Your server creates payments using tokenized Payment Instruments (4), which routes the request to an appropriate PSP.

Tokenized Payment Flow with MOTO

Mail order telephone order (MOTO) payments require merchant agents (for example call centre staff) to handle cardholder data, meaning it is not possible to achieve PCI-DSS SAQ-A. However, it is still possible to increase security while decreasing compliance costs by tokenizing cardholder data on your agents' client applications with BR-DGE via our Web SDK or Payment Instrument Tokenization Endpoints. The rest of your systems can then only deal with less sensitive tokens.

📘

You will need a dedicated MOTO-only retail channel for processing MOTO transactions.

3-D Secure Payment Flow

If 3-D Secure is applied to a payment then some actions may need to be performed on your client. These actions differ between individual PSPs, but this flow works with Web SDK to abstract away differences so that you only
need to deal with one flow.

1. Your server receives a 3-D Secure additional action required in response to a payment request.
2. Your server passes the action payload to your client.
3. The BR-DGE Web SDK provides functionality to handle the action, producing a nonce that you pass back to your server.
4. The nonce can be used to complete the payment using a ProviderThreeDSecureNonce Payment Instrument.
   • You may receive additional 3-D Secure additional action required responses depending on the underlying PSP, in which case return to step 1.

Please see the Payment with ProviderThreeDSecureNonce example payment request in POST /v1/payments for more details on the ProviderThreeDSecureNonce Payment Instrument.

Redirect Payment Flow

Some Payment Instruments use a Redirect Payment Flow and require the customer to be redirected to an external provider.

1. Your server sends a Client API Key to your client
2. The BR-DGE Web SDK will intelligently offer appropriate payment options to your customers
3. If your customer selects a redirect flow payment option then your client app informs your server along with checkout information
4. Your server makes a payment request, and a URL redirect action is returned
5. You pass the URL redirect action to the BR-DGE Web SDK running on your client app
6. The BR-DGE Web SDK will redirect your customer to the URL of the external provider
7. Once your customer has finished interacting with the external provider then they will be directed back to your client app
8. Your client app confirms the outcome of the payment via your server
9. Your server confirms the outcome of the payment via BR-DGE

📘

Some Payment Service Providers may have a delay when updating the payment status.

Card Payment Flow

Your server creates a payment containing cardholder data via the BR-DGE REST API (2), which routes the request to an appropriate Payment Service Provider (PSP).

❗️

By directly handling cardholder data, your platform will normally not qualify for the simplest PCI-DSS SAQ level.