Important notice:
Both existing and new merchants implement relevant integration changes on the client test environment and production environment within the deadlines and according to the instructions of their provider (acquirer).
3D Secure Card Payments
Merchant using the 3D Secure card payment is integrated using an HTTP API.
The requirements of the PSD2 RTS and card schemes impact this merchant, who needs to make changes in the current integration using an HTTP API.
Card schemes require the mandatory provision of the data indicated below for every card payment, with the main objective being to support the shopping process as much as possible without interruption by the authentication measures of the issuer through the application of the TRA (Transaction Risk Analysis) exemption from strong customer authentication by the acquirer or issuer:
- Name
- Email address
- Home phone number
- Mobile phone number
- Billing address
- Shipping address
In this case, merchant implements and uses the extended ADDINFO parameter for the transmission of the above data (see the up-to-date version of the "GP webpay API HTTP – Technical Specification").
Merchant will also update his general business terms and conditions and data protection policies to take account of the aforesaid personal data processing.
If strong customer authentication takes place, the liability for chargebacks with respect to such payments is transferred to the issuer, who is also liable for potential losses.
Providing that, based on a previous agreement between the acquirer and the merchant, the TRA exemption from strong customer authentication is applied by the acquirer with whom the merchant has concluded an agreement on payment cards acceptance on the Internet, the liability for chargebacks is not transferred to the issuer, and the acquirer is liable for potential losses, and may transfer this obligation to the merchant.
Providing that the TRA exemption from strong customer authentication is applied by the issuer, the liability for chargebacks is transferred to the issuer, who is liable for potential losses.
Please send your inquiries or requirements for implementation support to the email address gpwebpay@gpe.cz.
the One-click Payment function
A merchant using the One-click Payment function is integrated using a WS API (the ProcessRecurringPayment or processTokenPayment method).
The requirements of the PSD2 RTS and card schemes impact this merchant, who needs to make changes in the current integration using a WS API according to the relevant one-click payments scenario the merchant offers to their customers in their e-shop or application:
One-click Payment:
A customer clicks the “Pay” button in the e-shop or in the merchant’s application and is then redirected to their issuer for strong customer authentication.
In this case, the merchant will implement the new processCardOnFilePayment method (see the up-to-date version of the "GP webpay API WS – Technical Specification") document) and also an HTTP API (in the same scope as merchant using the 3D Secure card payment) to redirect the customer to their issuer for strong customer authentication.
The acquirer authorises the One-Click Payment function for the merchant.
If strong customer authentication takes place, the liability for chargebacks is transferred to the issuer, who is liable for potential losses.
Providing that, based on a previous agreement between the acquirer and the merchant, the TRA exemption from strong customer authentication is applied by the acquirer with whom the merchant has concluded an agreement on payment cards acceptance on the Internet, the liability for chargebacks is not transferred to the issuer, and the acquirer is liable for potential losses, and may transfer this obligation to the merchant.
Providing that the TRA exemption from strong customer authentication is applied by the issuer, the liability for chargebacks is transferred to the issuer, who is liable for potential losses.
Usage-based Payment:
A customer clicks the “Pay” button in the e-shop or in the merchant’s application but the payment is initiated by the merchant and processed via the GP webpay WS API later without redirecting the customer to the GP webpay payment gate – for example, payments initiated by a transport service application.
In this case, the merchant will implement the new processUsageBasedPayment method (see the up-to-date version of the "GP webpay API WS – Technical Specification") document). The acquirer authorises the Usage-Based Payment function for the merchant; with this type of payment, the liability for chargebacks does not transfer to the issuer and the acquirer is liable for potential losses, and may transfer this obligation to the merchant.
Please send your inquiries or requirements for implementation support to the email address gpwebpay@gpe.cz.
the Recurring Payment function
The requirements of the PSD2 RTS and card schemes impact this merchant, who needs to make changes in the current integration using a WS API according to the relevant scenario for subscriptions (recurring payments) based on their previous agreements with the customer:
Usage-based Subscription:
A customer agrees with the merchant on a “direct debit from a payment card” (similar to a direct debit from a bank account), for example regular payments for billing from a mobile telephone network operator (variable amount/fixed date).
In this case, the merchant will implement the new processUsageBasedSubscriptionPayment method (see the up-to-date version of the "GP webpay API WS – Technical Specification" document).
The acquirer authorises the Usage-Based Subscription for the merchant; this payment does not transfer the liability for chargebacks to the issuer, and the acquirer is liable for potential losses, and may transfer this obligation to the merchant.
Regular Subscription:
A customer agrees with the merchant on a regular subscription, e.g. a subscription to digital services (fixed amount/fixed date).
In this case, the merchant will implement the new processRegularSubscriptionPayment method (see the up-to-date version of the "GP webpay API WS – Technical Specification" document).
The acquirer authorises a Regular Subscription for the merchant; this payment does not transfer the liability for chargebacks to the issuer, and the acquirer is liable for potential losses, and may transfer this obligation to the merchant.
Prepaid Subscription:
A customer agrees with the merchant on recharging a prepaid service, e.g. a payment to recharge a prepaid card of a mobile telephone network operator with a fixed amount initiated by the stored value dropping below a defined level (fixed amount/variable date).
In this case, the merchant will implement the new processPrepaidPayment method (see up-to-date version of the "GP webpay API WS – Technical Specification" document).
The acquirer authorises the Prepaid Subscription for the merchant; this payment does not transfer the liability for chargebacks to the issuer, and the acquirer is liable for potential losses, and may transfer this obligation to the merchant.
Please send your inquiries or requirements for implementation support to the email address gpwebpay@gpe.cz.