Choosing an Integration Method
To accept payments from your payers using the Mastercard Gateway, you must select an integration method. These all allow you to gather payment details from the payer and create the necessary transactions to manage the full order life-cycle from initiating a single payment with payer participation to making recurring payments and providing refunds, as necessary.
The main integration methods are:
-
Hosted Checkout
This integration includes a payment page user interface (UI) hosted by the gateway. The gateway provides the UI to gather all payment details directly from the payer, so you do not need to handle sensitive Payment Card Industry (PCI) data at all. The solution is both secure and fast to deploy, but as it uses a predefined UI, it poses some limits to your ability to control the user experience.
-
Hosted Session
This integration allows you to define your own payment page to gather payment details from the payer. However, to achieve minimal PCI compliance costs, the payment page must use fields hosted by the gateway. That way the gateway gathers the payment data directly, and you have no need to handle it. The solution is more advanced than Hosted Checkout and allows you full control of the user experience. If you want to offer your payment solution to your payers as a mobile app, you can use the Mobile SDK to implement the Hosted Session integration for an app.
-
Direct Payment
This integration gives you full control over the payment page and the user experience. You collect and store the payment details from the payer yourself. The solution is the most advanced and the slowest to deploy, but it allows you to implement complex scenarios.
You must implement one of the above integration methods, as they allow you to implement cardholder-initiated transactions (CIT) which require the payer’s active participation (to authorize the payment you want to create).
If your business processes requires the batching of bulk operations together, for example CAPTURES or TOKENIZE, the Batch integration is available. It allows you to send large numbers of transactions to the gateway in a file-based batch. Keep in mind Batch is generally slower than API solution, as operations are processed at lower priority and then entire file must be uploaded and parsed before any processing starts and results downloaded.
Comparing the integration methods
The following table lists some of the key differences between the main integration methods, to make it easier for you to select the method that meets your specific business requirements.
| Feature | Hosted Checkout | Hosted Session | Direct Payment |
|---|---|---|---|
| Target PCI scope | SAQ-A compliant | SAQ-A compliant | SAQ-D compliant |
| API usage |
|
REST Server APIs | |
| Development effort |
|
|
|
| Payment page customizability |
|
|
Full control of the UI, flow, and the user experience |
PCI compliance
PCI is a set of security standards designed to safeguard sensitive payment card data. Merchants that handle card payments use a Self-Assessment Questionnaire (SAQ) to assess their compliance with PCI standards:
- SAQ-A is the simplest and most basic SAQ. It means that the merchant has outsourced all cardholder data processing to a PCI Data Security Standard (DSS)-compliant third-party service provider, in this case the Mastercard Gateway. Merchants with SAQ-A compliance cannot store, process, or transmit any cardholder data. They can handle e-commerce and mail/telephone order (MOTO) payments. If you are SAQ-A compliant, you must select the Hosted Checkout or Hosted Session integration method.
- SAQ-D is a more comprehensive SAQ, tailored to larger and more complex businesses that need to handle various kinds of payments. Merchants with SAQ-D compliance can store, process, and transmit cardholder data, and they are required to take the necessary security measures to protect the cardholder data entrusted to them. If you are SAQ-D compliant, you can use the Direct Payment integration method.
The gateway does not enforce specific PCI compliance. Your Payment Service Provider (PSP) and acquirers determine what kind of compliance they expect from you, and the gateway simply provides different integration methods to support you to meet those expectations. The support for both SAQ-A and SAQ-D compliance is available for both API integrations and transaction management through the Merchant Administration UI.
If you need to be SAQ-A compliant, your PSP must enable it in your merchant configuration (either for the API, UI, or both):
- If the SAQ-A compliance has been enabled for the UI, the gateway disables the order entry screens, preventing you from creating MOTO (mail/telephone) orders by entering card details.
Your payment service provider can also set you to be SAQ-A compliant in the UI, while giving you the option of breaking that compliance for some specific purpose. In that case, you can enable the View Unmasked Account Identifiers privilege for any of the operators you have created in the Merchant Administration. However, enabling that privilege for an operator breaks your SAQ-A compliance.
- If the SAQ-A compliance has been enabled for the API, the gateway rejects transactions that directly include PCI-sensitive cardholder data, such as the card number. You must instead include a container for cardholder data, such as a payment session or a token. The gateway also masks any Primary Account Numbers (PANs) in the transaction response.
If you are using the Batch integration, any batches containing unmasked PANs are rejected. If you request for unmasked PANs to be returned in the response, the gateway returns an error to enforce SAQ-A compliance.
If you need the ability to view unmasked PANs, contact your PSP to discuss your options.