The CQR Payment Service processes payments (deposits and/or withdrawals) initiated by a merchant on behalf of an end user. In addition, the CQR Payment Service offers functionality for payment method configuration, automated risk management, full workflow customization, reconciliation and settlement.

System architecture and technical characteristics

The CQR Payment Service is an encapsulated system containing a number of externally visible and internal applications. The diagram below highlights the principal externally visible components:

The CQR Payment System consists of the following applications:

1) RedirectPayments
A web application containing a set of web pages for displaying available payment methods, entering payment details and triggering payment

2) PaymentService
A web service that generates the appropriate URL for redirecting end users to the RedirectPayments web site, for directly triggering a new or modifying an existing payment, for getting payment details or available payment methods, and for many other other functions.

3) ProviderListeners
A web application that reacts to backend notifications from the provider and end-user redirections

4) PS Admin
A web application for administering the Payment Service. Administrators can view the payments in the system, invoke reports, manually create payments, reconfigure the routing, workflows, and other parameters, and perform many other functions.

The following communications take place between the applications in the CQR Payment System during the processing of an end-user payment:

1) Merchant System -> Payment Service (invoke, HTTPS/SOAP)
The merchant application invokes the getRedirectData over HTTPS/SOAP method in order to retrieve the redirect URL/POST data; alternatively invokes any other exposed service method.

2) Payment Service -> Merchant System (notify, HTTPS/SOAP)
The Payment Service invokes the handlePaymentStateChangedEvent method on the PaymentServiceListener service, which is implemented by the merchant.

3) End Users -> RedirectPayments (redirect, HTTPS/GET/POST)
The end user’s browser gets redirected to the RedirectPayments web application either via HTTPS POST or HTTPS GET.

4) End Users -> External Payment Service Providers (redirect, HTTPS/GET/POST)
The end user may get further redirected to the payment provider web site for authentication and transaction confirmation.

5) End Users -> ProviderListeners (redirect, HTTPS/GET/POST)
The end user gets redirected back to the ProviderListeners web application and then to the merchant application.

See the Payment Service Integration Manual in the download area for a diagram and detailed explanation of payment flow.

Technical integration

The integration approach offered is frontend-to-frontend and involves redirecting the end users to the CQR RedirectPayments web application for entering payment data. Once the payment is successfully processed, the user is redirected back to the merchant site.

A complete set of web services for backend-to-backend integration is also offered. These include the same web methods used by the CQR RedirectPayment application, plus additional methods for administrative and other purposes.

The technical integration of the CQR Payment Service consists of the following specific steps:

1. Implement a call to the getRedirectData web service method (create request, parse response)
2. Redirect the user to the CQR RedirectPayments application
3. Implement PaymentMethodSelection and Success/Error/Cancel/Refused/Pending static pages
4. Implement PaymentServiceListener web service and the handlePaymentStateChangedEvent method

For further details, see the Payment Service Integration Manual in the download area. Integration samples are also provided for a variety of programming languages and platforms.