GP webpay

Payments facilitating functionalities

Card on file

The Card on file functionality enables the merchant to store, in a simple and secure way, card details in GPE systems (card number and validity) for the purposes of:

• 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.

First, the customer has to give consent to the storage of card details in GPE systems. To store the card details, it is possible to use the so-called registration payment which is made in the same way as a standard 3D Secure payment, or the Card verification functionality.

To use the Card verification functionality, the customer is redirected to the payment page of GP webpay which offers only the payment method “Card payment” in the amount of CZK 0 (see Picture No. 9). It also displays a notice that only the card verification with the issuer bank will be performed and that no funds will be blocked or deducted.

Recurring payment

The functionality Recurring payment is defined by associations as a card payment associated with recurring billing with predetermined and by the customer pre-agreed conditions, such as a date and / or a fixed amount.

Initial settings

At first, the customer has to agree with the agreement regarding the accomplishment of a recurring payment by the merchant (Recurring Transaction Agreement - RTA). RTA has to specify:

• Amount and date
• If the amount / date is fixed or variable
• Way of communication with the customer

An obligation of the merchant is:

• To confirm the RTA to the customer within two days by the agreed way of communication
• RTA has to be retained over the duration of the agreement and provided at the request of the card issuer (by e-mail or in other electronic format, or in paper form)

Registration payment

The first one, the so-called registration payment, is made as a standard payment 3D Secure and the card holder has to be authenticated in that and the payment has to be made. If the payment is rejected, no other payments can be made under the given RTA and the merchant has to inform the customer.

Recurring payment - subscription

If the merchant offers a free trial period, the customer has to be informed 7 days in advance about the payment to be made at the end of that period.

The recurring payment is made by the use of API WS (Web Services) without redirecting the customer’s browser to the payment page for entering payment card data. The GP webpay authorizes directly the payment that is being made secured by SSL without authentication of the cardholder.

The merchant shall notify the customer about the upcoming expiration of his card and shall offer him/her an RTA renewal.

The merchant has to notify the customer at least seven working days before the next recurring payment in agreed way of communication in the following cases:

• It has been more than six months since the last payment
• The free trial period, the initial offer, or promotion action has finished
• In the RTA, there has been changed the amount and/or date given for the recurring payment

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-todate 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.

Cancellation

The merchant has to enable the customer an easy and feasible on-line cancellation of the recurring payment.

Also the customer’s card issuer can cancel the recurring payment for the customer. In that case the registration payment is invalidated and no recurring payments can be made to it.

Registration payment is invalidated automatically, if no recurring payment has been created to it over one calendar year, and no recurring payment can be created to it any more.

Creating a registration or recurring payment, it is described in the technical specification for developers.

Important notice: a recurring payment cannot be made for Maestro payment cards.

Fastpay

Fastpay feature enables the merchant to display on the payment page for the logged in customer last 4 digits of the payment card and the card validity of the card, which the customer has used for the previous payment (see Picture No. 10). The customer enters only verification code (CVC2/CVV2), the payment is created as a standard payment 3D Secure with cardholder’s authentication.

The merchant shall notify the customer in advance concerning the use of this functionality.

The customer can rewrite the displayed data and pay by other card.

Integration of e-shop to use this functionality is described in the technical specification for developers.

PUSH payment

PUSH payment functionality enables the merchant to create a payment request (so-called payment link). The merchant can create a PUSH payment in the GP webpay Portal (see Picture No. 11) or via API WS (see technical specification for developers).

The payment link can be sent to the customer by e-mail, or a QR code can be generated from it (e.g. to be placed on invoice, see Picture No. 12). If the customer decides to capture the PUSH payment, he/she clicks the link or scan the QR code and his/her browser is redirected to the GP webpay payment gateway, where the payment can be captured as in an e-shop.

The payment link can be used for recurring opening of the payment page and it is possible to make up to three payment attempts.