Frequently asked questions

Exclusions are transactions that are OUT of scope for PSD2 SCA regulations:

• Mail order/telephone order
• One leg journey - Payee's PSP (aka Merchant's acquirer) or Payer's PSP (aka Buyer's payment method issuer) is outside of EEA zone
• Anonymous prepaid cards up to 150€ (article 63)
• MIT - merchant initiated transactions

Exemptions are transactions that are IN the scope of PSD2 SCA regulations:

• Low value transactions
• Subscriptions
• Risk analysis
• Whitelisting

If you use our eCommerce page, Payglobe will take care of all mandatory fields.

If you are integrated in DirectLink, meaning that you have your own payment page, we have a Javascript example available on the support page to collect the mandatory data.

For the optional information collection, refer to our support page on how to integrate with Payglobe.

COF in a nutshell: Customer initiates a first transaction with a merchant with a 3D-S (CIT). From this first transaction experience, the merchant has the possibility to do recurring transactions (subscription or with customer approval -> tokenization), flagged as MIT transactions.

MIT are one of the exemptions foreseen within the 3DSv2., if they fulfill the following cumulative conditions:

• subsequent transactions of an initial CIT 
• CIT was done with a mandatory authentication
• A dynamic ID linking is made between initial CIT and the subsequent MITs

After initial authentication, exemptions/exclusions can apply:

• Either because of legal recurring exemptions which apply to subscriptions with a fixed amount and periodicity (merchants are indeed advised to authenticate for full amount + provide details about number of agreed payments with card holders)
• Either because other type of transactions are excluded from SCA scope... at merchant sole risk in case of chargeback (protection limited to authenticated amount) AND need for issuer to accept that risk to be taken:
  • Unscheduled COF: principle of subsequent transactions is agreed with card holder, but amount and/or periodicity is not fixed
  • Industry practices: incremental, no show, etc...

For the transitional period, schemes have defined default ID to be used for subsequent MITs created before introduction of 3DS v2.

Our test platform is ready for you to start testing. A simulator will support all different scenarios.

Testing cards have been provided and can be found on the support site, as well as in the TEST environment (Configuration > Technical Information > Test info).

Please contact us should you wish to start using 3-D Secure version 2 (3DSv2) in production. 

Secure version 2 is an evolution of the existing 3-D Secure version 1 programs: Verified by Visa, Mastercard SecureCode, AmericanExpress SafeKey, Diners/Discover ProtectBuy and JCB J/Secure. It is based on a specification that has been drafted by EMVco. EMVCo exists to facilitate worldwide interoperability and acceptance of secure payment transactions. It is overseen by EMVCo’s six member organizations—American Express, Discover, JCB, Mastercard, UnionPay, and Visa—and supported by dozens of banks, merchants, processors, vendors and other industry stakeholders who participate as EMVCo Associates.

One of the core differences in version 2 is that the issuer can use a lot of data-points from the transaction to determine the risk of the transaction (risk-based analysis). For low-risk transactions, issuers will not challenge the transaction (e.g. not sending an SMS to the cardholder) although authenticating the transaction (frictionless). Inversely, for high risk transaction, issuers will require the cardholder to authenticate with an SMS or biometric means (challenge).

Separately the Strong Customer Authentication (SCA) required from 1st January 2021 for Europe and from 14th September 2021 for UK, 2019 as specified in PSD2 will result in a substantial increase in the number of transactions requiring the use of 3-D Secure authentication. The use of 3-D Secure version 2 should limit the potential negative impact on conversion as much as possible. In short 3-D Secure version 2 means:

• You will need to implement 3-D Secure before January 1st, 2021 if your transactions fall within the EU PSD2 SCA guidelines (in case you don't already support 3-D Secure).
• You are advised (and for some are required) to submit additional data points to support the risk assessment performed by the issuer in case of 3-D Secure version 2
• You might need to update your privacy policy with regards to GDPR as you might be sharing additional data-points with 3rd parties
• A much better user experience for your consumers

The expectation in the market is that a substantial percentage of transactions using 3-D Secure version 2 will follow the frictionless flow, which doesn't require anything additional from the cardholder compared to current non-3-D Secure checkout flows. This means that you benefit from the increased security and liability shift that is provided by the 3-D Secure programs, while the conversion in your checkout process shouldn't be negatively impacted.

The EBA (European Banking Authority) and national banks in each affected country agreed on a grace period (until at least March 2020). This will give every player in the eCommerce business the opportunity to clarify all details related to this new regulation. However, we still strongly recommend to activate 3DS in your account(s) as soon as possible.

Since our TEST environment is ready, we advise you to start testing your integration as soon as possible.

To make things easier for both merchants and consumers, PSD2 allows for some exemptions from strong customer authentication. What’s important to note is that all transactions that qualify for an exemption won’t be automatically exempted. In the case of card transactions, for example, it’s the card issuing bank that decides if an exemption is approved or not. So, even if a transaction qualifies for an exemption the customer might still have to make a strong customer authentication, if the card issuing bank chooses to demand it.

If the issuer is applying new PSD2 ruleset and 3DS is not active in the merchant's account, the transaction will be rejected with a new error code - soft decline. Therefore, please make sure to have 3DS active for each brand in your account(s). If you are integrated with DirectLink (Server to Server), you will need to implement the soft decline mechanism.

This situation is only possible if you are integrated via DirectLink only (Merchant own page / FlexCheckOut), as in Payglobe hosted payment page page, Payglobe is collecting the mandatory data.

First of all, Payglobe will identifiy the flow to be directed to v1 or v2 based on the card numbers.

If the card is enrolled V2, there are the following possible scenarios:

Mandatory data:

• If the wrong data is passed, transaction is blocked
• If some data is missing, Payglobe will direct your transaction to v1 flow
• If no data is passed, transaction is NOT blocked but diverted to flow v1

Recommended or optional data:

• if no data is passed, transaction is NOT blocked, but cannot benefit from exemption. 

From 1st January 2020 for Europe and from 14th September 2021 for UK, Strong Customer Authentication (SCA) rules will come into effect for all digital payments in Europe. Right now, banks, payment service providers and card networks are all working on technical solutions that will comply with the requirements for PSD2. To accept payments after January 1st you will have to make sure that these technical solutions will work with your online store.

Accepting payments from the world’s largest card networks, Visa, Mastercard and Amex, will require that you have implemented the security solution 3D Secure for your online store. 3D Secure has been used since 2001 to improve the security for online card transaction but now a new version has been developed that will facilitate the PSD2 Strong Customer Authentication requirements.

We recommend you to use 3-D Secure, since it helps prevent fraud and also protects you from liability in case of any fraud. From January 1st 2020 it will also be a requirement for accepting the payments from major cards.

3DSv2 is inviting merchants to send additional information (mandatory / recommended ... ). All you need to know as a merchant can be found here:

In addition to that we have added the new parameter VERSION_3DS to our electronic reporting tool.

The possible values for VERSION_3DS are

V1  (for 3DS v1)
V2C (for 3DS v2 challenge flow)
V2F (for 3DS v2 frictionless flow) 

To add this parameter to your transaction file downloads, follow the instructions as shown in this video:

In a case like this, Payglobe will automatically manage a fallback to 3-D Secure v1.

The EU’s Second Payment Services Directive (2015/2366 PSD2) entered into force in January 2018, aiming to ensure consumer protection across all payment types, promoting an even more open, competitive payments landscape. Acting as a payment service provider, we pride ourselves on being confirmed PSD2 compliant since 29 May 2018.

One of the key requirements of PSD2 relates to Strong Customer Authentication (SCA) that will be required on all electronic transactions in the EU from 1st January 2021 for Europe and from 14th September 2021 for UK. SCA will require cardholders to authenticate themselves with at least TWO out of the following three methods:

• Something they know (PIN, password, …)
• Something they possess (card reader, mobile. …)
• Something they are (voice recognition, fingerprint, …

This means your customers, in practice, will no longer be able to make a card payment online by using only the information on their cards. Instead they will have to, for example, verify their identity on a bank app that is connected to their phone and requires a password or fingerprint to approve the purchase.

More information about PSD2 can be found here: https://www.europeanpaymentscouncil.eu/sites/default/files/infographic/2018-04/EPC_Infographic_PSD2_April%202018.pdf

Even though we advise against using it since this feature will no longer be supported from 25 August 2020, you can configure the so-called referrer check, in addition to the SHA signature authentication. With this setting, our system checks the origin of the transaction request which is the URL the request comes from (the referrer). The aim is so that unauthorised URLs (that were not configured in your account) will not be able to call the payment page.

In order to set it up or remove it, simply go to Technical Information > Data and origin verification. Under Checks for e-Commerce & Alias Gateway, you can enter one or more URLs that you want to enable to call the payment page: orderstandard.asp / orderstandard_utf8.asp.

Possible errors related to the referrer are "unknown order/1/r" and "unknown order/0/r". Go to Possible errors for more information about these errors.

Important: We strongly advise against it and therefore to leave it blank.

However, if you would still like to use it,

• The URL(s) must always start with http:// or https://
• You must enter the ‘origin’ of the URL being accepted (Origin: <scheme> "://" <hostname> [ ":" <port> ])’ (For example: https://www.mysite.net)
• If you have several domains, multiple URLs can be entered. For example, http://www.mysite.com;http://www.mysite.net;https://www.secure.mysite.com. The URLs must be separated by a semicolon, with no spaces before or after the semicolon.
• If you perform a test transaction from our test page, please remember to enter our site’s origin URL as a referrer, otherwise you will receive an error.

We also would like to take the opportunity to remind you that although the referrer allows our system to identify the origin of an order, SHA signature authentication remains the most trusted way to secure your transactions on your PSPID. You can find more information on that in our SHA signature integration guide.

You can only perform refunds on transactions which have already received status 9 for at least 24 hours. A cancellation or deletion can be done within approximately 24 hours after final status has been received (status 9 or 5).

To know the cut-off time of the acquirer, we recommend you to check directly with our Customer Care department.

A full green thumbs-up icon means that the transaction was completed with a 3-D Secure authentication method, such as Digipass or a card reader. However, it doesn't necessarily mean the payment itself was processed successfully. Therefore, you should always check the transaction status to know whether you'll receive your money.

Go to Transaction statuses for more information.

You can easily refund a payment with the "Refund" button in the order overview of a transaction (via View transactions). If your account supports it, you can also make refunds with a DirectLink request or with a Batch file upload (for multiple transactions).

Please note that the Refunds option has to be enabled in your account.

Go to Maintain your transactions for more information.

By default you can send goods or deliver your service once a transaction has reached the status "9 - Payment requested". However, although status 5 is a successful status, it's only a temporary reservation of an amount of money on the customer's card. A transaction in status 5 still needs to be confirmed (manually or automatically) to proceed to the status 9, which is the final successful status for most payment methods.

Go to Transaction statuses for more information.

In your Payglobe account menu, you can easily lookup your transactions by choosing "Operations" and then clicking either "View transactions" or "Financial history", depending on the type of transaction results you're looking for.

Go to Consult your transactions for more information.

Payglobe offers a complete suite of flexible products, sophisticated technologies and dedicated expertise to help you manage and optimize your online fraud prevention practices. Our industry-leading fraud detection tools and experts bring over 20 years of industry and regional expertise, and we will work closely with you to develop, implement and manage a holistic fraud solution that includes prevention, detection and management. We also offer comprehensive chargeback management and dispute management solutions. 

By working with Payglobe, you can pick the solutions that best fit your needs and customize our services to either outsource fraud management functionalities or keep them in-house with our ongoing support.

3-D Secure is a way to authenticate online transactions, similar to enter a PIN code or writing a signature for a transaction on a physical terminal in a shop or restaurant. It was initially developed by VISA under the name "Verified by VISA" and was soon adopted by MasterCard (SecureCode), JCB (J/Secure) and American Express (Safekey®).

There are several forms of 3-D Secure authentication. Depending on the customer's bank and originating country, it can be using a card reader or digipass, entering a PIN-code, or entering a piece of data that only the cardholder can know. 3-D Secure allows merchants selling online to verify that their customers are the genuine cardholder in order to reduce instances of fraud.

If you want to check specific details of an order/transaction or perform maintenance on transactions, you should use View transactions. "Financial history" is the most convenient to periodically check incoming and outgoing funds.

For more information, go to View transactions vs Financial history.

There are different reasons why you can't refund a transaction. You need to consider the following (with the condition that the Refund option is enabled in your account):

• The transaction is in an "incomplete" status, such as a pending or erroneous status (91, 92 etc.) that doesn't allow the refund operation.
• If the transaction is authorised (status 5), at which point no payment has been made yet. In this case you have to cancel the authorisation instead of refund.
• The used payment method doesn't support the refund functionality, which can be the case with certain debit cards, web banking methods and "offline" payment methods such as Bank transfer.

The message "An error has occurred; please try again later. If you are the owner or the integrator of this website, please log into the Payglobe back office to see the details of the error." is a generic error message which is returned if a specific technical issue occurs at the moment the payment page is called. We don't display the actual error on the payment page, mainly because of security reasons, but also not to confuse your customers.

In your Payglobe account, via "Configuration" > "Error logs", you can easily look up the errors that occurred when the generic error message was displayed. The actual meaning of these errors are described on the Possible errors page.

You can reinitiate your password via the  "Lost your password?" button on the bottom of the login screen.

If you're unable to log in to your account using your payment service provider ID (PSPID) and password, it may be due to one of the following reasons:

• You could be using your test PSPID and/or password in the production environment, or your production PSPID and/or password in the test environment. You can check the environment at the top of the login screen – it will say either: "Identification Production" or "Identification TEST". To switch environments, use the link under the login fields.
• You could be logging in as a merchant on the user screen or as a user on the merchant screen. If you're logging in as a merchant, you'll see two fields: PSPID and Password. If you're logging in as a user, you'll see three fields: USERID, PSPID (optional) and Password. To switch the login screen, click the "Log in as user" or "Log in as PSPID" button on the bottom left of the screen.
• Perhaps you've typed in your password in the wrong case? Passwords are case sensitive. Try typing your password into a text editor such as Word or Notepad to check the spelling and the case, then copy/paste the result in the password field.
• When you submit your login details, if the login page reappears and the information you entered is gone it means your browser is not accepting session cookies. To enable session cookies, go to your browser's settings. If you're unsure how to do this for your operating system and browser version, please check with an IT specialist. 

If you forgot your password, please click on the "Lost your password?" button on the bottom of the screen.

Once a transaction reaches status 9, meaning that the customer has paid, the acquirer or bank will deposit the money to your account. The time when this payout occurs differs per payment method and acquirer. We recommend you to check directly with the acquirer or bank, if you believe you're not receiving your money in a timely manner.