CQR offers 2 kinds of service levels:
- CQR Payment Solutions GmbH: Payment Gateway
- CQR UK Payment Solutions Ltd: Aggregation
Those 2 service levels have both business and process implications.
Through a single interface to the merchant, CQR enable a multitude of payment method and access to multiple acquirers – thus providing a payment platform for interactive payments.
Our services include currency conversions, domestic and international remittance, a back office administrative application (payment service admin aka PS admin) and consistent reporting.
In addition, several value-add services, including risk management and 3D Secure for credit card payments, are available.
Payment Gateway
A payment gateway service level includes 3 different solutions:
- Settlement
- Authorisation and Capture
- Authorisation
The following diagram lists the processing flow in regards to a credit or debit card transaction, but can also be applied for any other payment transaction in a similar fashion:

Key players
|
Card holder |
A customer holding a credit or debit card, such as VISA or MasterCard |
|
Issuer |
A financial institution – such as a bank – issuing the corresponding cards and maintaining a contract with card holders for repayment |
|
Merchant |
An authorized acceptor for a credit or debit card for the payment of goods and services |
|
Acquirer |
A financial institution or merchant bank having a contract with the merchant for acceptance of a certain credit or debit card |
Typical Payment Gateway Transaction Flow
| (1) |
The customer (cardholder) is purchasing goods or services from the merchant. |
| (2) |
The customer is redirected to the payment details page in the Redirect Payments solution and |
| (3) |
Enters data on that web page or backend-to-backend implementation is used between the merchant’s website and CQR’s payment service. |
| (4) |
An authentication request is sent from CQR to the payment processor or acquirer and forward to the card’s issuer (usually the card holder’s bank). |
| (5) |
The card’s issuer sends an authorisation (or declines the transaction), which this state being remitted to CQR and the merchant. |
| (6) |
The merchant will now prepare the product and ship it to the customer. For online service thus this may happen immediately, for other goods there may be a certain time delay between authorisation and capture (also called clearing). |
| (7) |
The merchant will send a capture request to CQR, from where it will be forwarding through the acquirer to the issuer. |
| (8) |
The issuer posts the transaction to the card holder account and settles the transaction with the acquirer. |
|
(8a) In turn the acquirer credits the merchant’s accounts and.. |
|
(8b) transmits the Electronic Payment Advice (EPA) reconciliation files to CQR |
|
(8c) CQR will provide a settlement report for the merchant. |
Aggregation
The following diagram lists the processing flow in regards to a credit or debit card transaction, but can also be applied for any other payment transaction in a similar fashion:
Processing flow (aggregation)
Full cash management (funds through CQR)

Typical Aggregation Transaction Flow
The steps (1) through (7) are the same as with the gateway process flow in the above paragraph.
| (1) |
The customer (cardholder) is purchasing goods or services from the merchant. |
| (2) |
The customer is redirected to the payment details page in the Redirect Payments solution and |
| (3) |
Enters data on that web page or backend-to-backend implementation is used between the merchant’s website and CQR’s payment service. |
| (4) |
An authentication request is sent from CQR to the payment processor or acquirer and forward to the card’s issuer (usually the card holder’s bank). |
| (5) |
The card’s issuer sends an authorisation (or declines the transaction), which this state being remitted to CQR and the merchant. |
| (6) |
The merchant will now prepare the product and ship it to the customer. For online service thus this may happen immediately, for other goods there may be a certain time delay between authorisation and capture (also called clearing). |
| (7) |
The merchant will send a capture request to CQR, from where it will be forwarding through the acquirer to the issuer. |
| (8) |
The issuer posts the transactions to the card holder account and settles the transaction with the acquirer. |
|
(8a) The acquirer transmits the Electronic Payment Advice (EPA) reconciliation file to CQR. |
|
(8b) The acquirer remits the funds to CQR. |
|
(8c) CQR provides settlement files for the merchant. |
CQR remits funds to the merchant.
Merchant Payment Batches
In the aggregation model, payment providers remit funds and send settlement batches to CQR.
CQR’s merchant operations department will mark batches as “Settled with Provider” and have a batch for the merchant be created.
In the Payment Service Admin application, merchant can select the menu item “Payment Batching” and it`s subsection “Payment Batches”.
Batches marked “Settled with Merchant” indicate funds that have already been transferred to the merchant’s bank account. The merchant can download information – including gross and net value of the batch - as CSV and XML format.
Service Level Summary
|
Description |
Acquirer relationship owned by |
Money flow through |
Reconciliation model |
Merchants |
Payment types |
|
Full Cash Management |
CQR Aggregation |
CQR bank accounts |
Funds & EPA files |
Merchant outsourcing the full payment processing |
All payments under aggregation deals |
|
Settlement |
Merchant |
Provider & Merchant |
EPA files |
Merchants with own MIDs that want settlement and reporting |
Cards |
|
Authorisation & Capture |
Merchant |
Provider & Merchant |
n/a |
Merchants with own MIDs who don’t want reconciliation |
Cards |
|
Authorisation |
Merchant |
Provider & Merchant |
n/a |
Merchants with own MIDs who need us for real-time auth. only |
Cards |
Note: MIDS = merchant ID, the ID a merchant does have at a payment processor or acquirer
In the payment gateway offering, the acquirer relationship is owned by the merchant: The merchant needs to sign a contract directly with the acquirer and accordingly funds will flow between provider and merchant.
In contrast, with the aggregation model we offer full cash management for the merchant. The funds will flow through the CQR bank accounts. This model is available for many payment methods.