What are the impacts of the requirements of the PSD2 RTS on e-commerce merchants with the GP webpay payment gateway?
I am a merchant who uses
3D Secure Card Payments
I am a merchant who uses
the One-click Payment function
I am a merchant who uses
the Recurring Payment function

Important notice:
The existing merchant implements relevant changes in integration on the client test environment by August 31, 2019. The provider (acquirer) will inform of the deadline for implementing changes in integration in the production environment.

The new merchant implements both existing integration and related changes on the client test environment. It only implements existing integration on a production environment. The provider (acquirer) will inform of the deadline for implementing changes in integration in the production environment.

I am a merchant who uses
3D Secure Card Payments

A merchant who uses 3D Secure Card Payments or other payment methods and functions (Fastpay, PUSH Payments, Masterpass, Google Pay, DCC, PLATBA 24/Payments by bank account) is integrated using API HTTP.

There are no impacts of the PSD2 RTS for such, no changes need to be made to the current integration using API HTTP.

The merchant can allow a customer to carry out a 3D Secure card payment without a redirection to the issuing bank (issuer) and without strong customer authentication provided that the merchant implements and uses the extended parameter of ADDINFO (see the up-to-date version of the document "GP webpay API HTTP – Technical Specification"), in which they provide information required for the Transaction Risk Analysis (TRA) of the given payment.

Providing that, based on a previous agreement between the acquirer and the merchant, the TRA exemption from the strong customer authentication is applied by the acquirer with whom the merchant has concluded an agreement on payment cards acceptance on the Internet, the responsibility for chargebacks is not transferred to the issuer and potential damages are the responsibility of the acquirer, who can transfer this duty to the merchant.

Providing that the TRA exemption from the strong customer authentication is applied by the issuer, the responsibility for chargebacks is transferred to the issuer, who is responsible for potential damages (status quo).

Please send your inquiries or requirements for support in the implementation to the e-mail address gpwebpay@gpe.cz.

I am a merchant who uses
the One-click Payment function

A merchant who uses the One-click Payment function is integrated using API WS (the processRecurringPayment or processTokenPayment method).

The requirements of PSD2 RTS have impacts for the merchant, who needs to make changes in the current integration using API WS according to the relevant scenario for One-click payments which 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 the payment is immediately processed via the GP webpay API WS without redirecting the customer to the GP webpay payment gate.

In this case, the merchant shall implement the new method of processCardOnFilePayment (see the up-to-date version of the document "GP webpay API WS – Technical Specification"). API HTTP must also be implemented in case the processCardOnFilePayment method response is with a requirement for redirecting the customer to their issuing bank (issuer) to ensure a strong customer authentication.

The acquirer authorises the One-click Payment function for the merchant; this payment does not transfer the responsibility for chargebacks to the issuer and potential damages are the responsibility of the acquirer, who can transfer this duty to the merchant.

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 API WS later without redirecting the customer to the GP webpay payment gate, take a payment initiated by a transport service application such as Uber as an example.

In this case, the merchant shall implement the new method of processUsageBasedPayment (see the up-to-date version of the document "GP webpay API WS – Technical Specification").

The acquirer authorises the Usage-based Payment function for the merchant; this payment does not transfer the responsibility for chargebacks to the issuer and potential damages are the responsibility of the acquirer, who can transfer this duty to the merchant.

Please send your inquiries or requirements for support in the implementation to the e-mail address gpwebpay@gpe.cz.

I am a merchant who uses
the Recurring Payment function
A merchant who uses the Recurring Payment function is integrated using API WS (the processRecurringPayment method).

The requirements of PSD2 RTS have impacts for the merchant, who needs to make changes in the current integration using API WS according to the relevant scenario for subscriptions (recurring payments) based on a previous agreement with the customer:

Usage-based Subscription:

A customer agrees with the merchant on a "direct debit from the payment card" (similar to a direct debit from a bank account), for example, on a regular payment for invoices from a mobile telephone network operator (variable amount/fixed date).

In this case, the merchant shall implement the new method of processUsageBasedSubscriptionPayment (see the up-to-date version of the document "GP webpay API WS – Technical Specification").

The acquirer authorises the Usage-based Subscription for the merchant; this payment does not transfer the responsibility for chargebacks to the issuer and potential damages are the responsibility of the acquirer, who can transfer this duty to the merchant.

Regular Subscription:

A customer agrees with the merchant on a regular subscription, e.g. a subscription to digital services such as Netflix (fixed amount/fixed date).

In this case, the merchant shall implement the new method of processRegularSubscriptionPayment (see the up-to-date version of the document "GP webpay API WS – Technical Specification").

The acquirer authorises a Regular Subscription for the merchant; this payment does not transfer the responsibility for chargebacks to the issuer and potential damages are the responsibility of the acquirer, who can transfer this duty to the merchant.

Prepaid Subscription:

A customer agrees with the merchant on reloading a prepaid service, e.g. a payment to reload a stored value card of a mobile telephone network operator with a fixed amount initiated by a drop of the stored value below the defined level (fixed amount/variable date).

In this case, the merchant shall implement the new method of processPrepaidPayment (see up-to-date version of the document "GP webpay API WS – Technical Specification").

The acquirer authorises the Prepaid Subscription for the merchant; this payment does not transfer the responsibility for chargebacks to the issuer and potential damages are the responsibility of the acquirer, who can transfer this duty to the merchant.

Please send your inquiries or requirements for support in the implementation to the e-mail address gpwebpay@gpe.cz.