Google Pay™ 3DS processing for Cryptogram_3DS and PAN_ONLY
Please note, that due to PSD2 regulation, payments need to have SCA (Strong Customer Authentication). This also applies to Google Pay™. Google Pay™ in general is providing 2 types of payload containing payment data.
In case of CRYPTOGRAM_3DS payload, payment is already SCA authenticated on the customer device, payload contains proof of authentication and therefore there is no need for addition SCA in form of 3-D Secure.
In case of PAN_ONLY payload, payment data are not SCA authenticated. Therefore in order to avoid Soft Declines, 3-D Secure authentication is required.
Below guide describes how 3-D Secure 2.0 can be applied for Google Pay payments.
This guide can be applied for all Google Pay payments, because will dynamically recognize PAN_ONLY payloads and start the 3-D Secure process. In case of CRYPTOGRAM_3DS payload, 3-D Secure will not be started.
A 3-D Secure 2.0 payment sequence may comprise the following distinct activities:
Versioning
Request ACS and DS Protocol Version(s) that correspond to card account range as well as an optional 3-D Secure Method URL
3-D Secure Method
Connect the cardholder browser to the issuer ACS to obtain additional browser data
Authentication
Submit authentication request to the issuer ACS
Challenge
Challenge the card holder if mandated
Authorization
Authorize the authenticated transaction with the acquirer
Server-2-Server Sequence Diagram
Please note that the the communication between client and Access Control Server (ACS) is implemented through iframes. Thus, responses arrive in an HTML subdocument and you may establish correspondent event listeners in your root document.
Alternatively you could solely rely on asynchronous notifications delivered to your backend. In those cases you may have to consider methods such as long polling, SSE or websockets to update the client.
Payment Initiation
The initial request to will be the same regardless of the underlying 3-D Secure Protocol.
In order to start Google Pay™ 3-D Secure payment sequence please post the following key-value-pairs to googlepay.aspx.
Call of interface: general parameters
To carry out a Google Pay payment via a Server-to-Server connection, please use the following URL:
With 3-D Secure 2.x a lot of additional data were required (e.g. browser-information, billing/shipping-address, account-info, ...) to improve authentication processing. To handle these information theJSON-objectshave been put in place to handle such data. To indicate that these data are used the MsgVer has been implemented.
To avoid double payments or actions (e.g. by ETM), enter an alphanumeric value which identifies your transaction and may be assigned only once. If the transaction or action is submitted again with the same ReqID,Axepta Platformwill not carry out the payment or new action, but will just return the status of the original transaction or action.
Please note that theAxepta Platformmust have a finalized transaction status for the first initial action (authentication/authorisation). This does not apply to 3-D Secure authentications that are terminated by a timeout. The 3-D Secure Timeout status does not count as a completed status in which the ReqID functionality onPlatformdoes not take effect. Submissions with identical ReqID for an open status will be processed regularly.
Notice:Please note that a ReqID is only valid for 12 month, then it gets deleted at thePlatform.
Merchant’s unique reference number, which serves as payout reference in the acquirer EPA file. Please note, without the own shop reference delivery you cannot read out the EPA transaction and regarding the additional settlement file (CTSF) we cannot add the additional payment data.
Details on supported format can be found below in payment specific section.
MultiExcerpt named RefNr_Ascii was not found -- Please check the page name and MultiExcerpt name used in the MultiExcerpt-Include macro
Eindeutige Referenznummer des Händlers, welche als Auszahlungsreferenz in der EPA-Datei des Acquirers dient.Bitte beachten Sie, dass ohne die eigene Shop-Referenzlieferung die EPA-Transaktion nicht ausgelesen werden kann und wir die zusätzlichen Zahlungsdaten nicht in die zusätzlicheThe page DE:Wording was not found -- Please check/update the page name used in the MultiExcerpt-Include macroAbrechnungsdatei (CTSF) aufnehmen können.
Einzelheiten zum unterstützten Format finden Sie weiter unten im zahlungsspezifischen Abschnitt.
The page DE:Reuse API was not found -- Please check/update the page name used in the MultiExcerpt-Include macro
No Table Excerpt macro with name Amount_REST found. Did you publish the page with the Table Excerpt macro?
No Table Excerpt macro with name Currency_REST found. Did you publish the page with the Table Excerpt macro?
No Table Excerpt macro with name Capture_REST found. Did you publish the page with the Table Excerpt macro?
The customer that is getting billed for the goods and / or services. Required unless market or regional mandate restricts sending this information.
Der Kunde, dem die Waren und / oder Dienstleistungen in Rechnung gestellt werden. Erforderlich, sofern nicht Markt- oder regionale Mandate das Senden dieser Informationen beschränken.
No Table Excerpt macro with name URLNotifyCC_REST found. Did you publish the page with the Table Excerpt macro?
No Table Excerpt macro with name MAC_REST found. Did you publish the page with the Table Excerpt macro?
Channel over which the order is processed. Allowed values are WEBSITE and MOBILE_APP.
The channel parameter is mandatory for RedSys. Please provide it if your processor is RedSys. For other processors, it is not obligatory to provide this information.
Kanal, über den die Bestellung abgewickelt wird. Erlaubt sind die Werte WEBSITE und MOBILE_APP.
Der Parameter Channel ist für RedSys obligatorisch. Bitte geben Sie ihn an, wenn Ihr Prozessor RedSys ist. Für andere Prozessoren ist die Angabe dieser Information nicht obligatorisch.
General parameters for credit card payments via socket connection
Please note the additional parameter for a specific credit card integration in the section "Specific parameters"
The Card Range Data data element contains information that indicates the most recent EMV 3-D Secure version supported by the ACS that hosts that card range. It also may optionally contain the ACS URL for the 3-D Secure Method if supported by the ACS and the DS Start and End Protocol Versions which support the card range.
Das Datenelement Card Range Data enthält Informationen, welche die jüngste vom ACS, der den Kartenbereich hostet, unterstützte EMV 3-D Secure-Version angeben. Es kann optional auch die ACS URL für die 3-D Secure Methode enthalten, falls vom ACS unterstützt, sowie die DS Start- und End-Protokoll-Versionen, die den Kartenbereich unterstützen.
Object containing the data elements required to construct the Payer Authentication request in case of a fallback to 3-D Secure 1.0.
Objekt, dass die erforderlichen Datenelemente für die Konstruktion der Anfrage zur Zahler-Authentisierung im Falle eines Fallbacks auf 3-D Secure 1.0 enthält.
versioningData
The versioningData object will indicate the EMV 3-D Secure protocol versions (i.e. 2.1.0 or higher) that are supported by Access Control Server of the issuer.
If the corresponding protocol version fields are NULL it means that the BIN range of card issuer is not registered for 3-D Secure 2.0 and a fallback to 3-D Secure 1.0 is required for transactions that are within the scope of PSD2 SCA.
When parsing versioningData please also refer to the subelement errorDetails which will specify the reason if some fields are not pupoluated (e.g. Invalid cardholder account number passed, not available card range data, failure in encoding/serialization of the 3-D Secure Method data etc).
The 3-D Secure Method allows for additional browser information to be gathered by an ACS prior to receipt of the authentication request message (AReq) to help facilitate the transaction risk assessment. Support of 3-D Secure Method is optional and at the discretion of the issuer.
The versioningData object contains a value for threeDSMethodURL. The merchant is supposed to invoke the 3-D Secure Method via a hidden HTML iframe in the cardholder browser and send a form with a field named threeDSMethodData via HTTP POST to the ACS 3-D Secure Method URL.
3-D Secure Method: threeDSMethodURL
Please note that the threeDSMethodURL will be populated by if the issuer does not support the 3-D Secure Method. The 3-D Secure Method Form Post as outlined below must be performed independently from whether it is supported by the issuer. This is necessary to facilitate direct communication between the browser and in case of a mandated challenge or a frictionless flow.
The ACS will interact with the Cardholder browser via the HTML iframe and then store the applicable values with the 3-D Secure Server Transaction ID for use when the subsequent authentication message is received containing the same 3-D Secure Server Transaction ID.
Once the 3-D Secure Method is concluded the ACS will instruct the cardholder browser through the iFrame response document to submit threeDSMethodData as a hidden form field to the 3-D Secure Method Notification URL.
ACS Response Document
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8"/>
<title>Identifying...</title>
</head>
<body>
<script>
var tdsMethodNotificationValue = 'eyJ0aHJlZURTU2VydmVyVHJhbnNJRCI6ImUxYzFlYmViLTc0ZTgtNDNiMi1iMzg1LTJlNjdkMWFhY2ZhMiJ9';
var form = document.createElement("form");
form.setAttribute("method", "post");
form.setAttribute("action", "notification URL");
addParameter(form, "threeDSMethodData", tdsMethodNotificationValue);
document.body.appendChild(form);
form.submit();
function addParameter(form, key, value) {
var hiddenField = document.createElement("input");
hiddenField.setAttribute("type", "hidden");
hiddenField.setAttribute("name", key);
hiddenField.setAttribute("value", value);
form.appendChild(hiddenField);
}
</script>
</body>
</html>
Please note that the threeDSMethodNotificationURL as embedded in the Base64 encoded threeDSMethodData value points to and must not be modified. The merchant notification is delivered to the URLNotify as provided in the original request or as configured for the MerchantID in .
Authentication
If 3-D Secure Method is supported by the issuer ACS and was invoked by the merchant will automatically continue with the authentication request once the 3-D Secure Method has completed (i.e. 3-D Secure Method Notification).
The authentication result will be transferred via HTTP POST to the URLNotify. It may indicate that the Cardholder has been authenticated, or that further cardholder interaction (i.e. challenge) is required to complete the authentication.
In case a cardholder challenge is deemed necessary will transfer a JSON object within the body of HTTP browser response with the elements acsChallengeMandated, challengeRequest, base64EncodedChallengeRequest and acsURL. Otherwise, in a frictionless flow, will automatically continue and respond to the cardholder browser once the authorization completed.
Response object in return of the authentication request with the ACS
Antwort-Objekt als Rückgabe zur Authentisierungs-Anfrage beim ACS
Browser Challenge
If a challenge is deemed necessary (see challengeRequest) the browser challenge will occur within the cardholder browser. To create a challenge it is required to post the value base64EncodedChallengeRequest via an HTML iframe to the ACS URL.
You may use the operations init3DSChallengeRequest or createIFrameAndInit3DSChallengeRequest from the nca3DSWebSDK in order submit the challenge message through the cardholder browser.
Once the cardholder challenge is completed, was cancelled or timed out the ACS will instruct the browser to post the results to the notfication URL as specified in the challenge request and to send a Result Request (RReq) via the Directory Server to the 3-D Secure Server.
Please note that the notification URL submited in the challenge request points to and must not be changed.
Authorization
After successful cardholder authentication or proof of attempted authentication/verification is provided will automatically continue with the payment authorization.
In case the cardholder authentication was not successful or proof proof of attempted authentication/verification can not be provided will not continue with an authorization request.
In both cases will deliver a notification with the authentication result to the merchant specified URLNotify with the data elements as listed in the table below.
Payment Notification
MultiExcerpt named KvpResponse_IntroURL was not found -- Please check the page name and MultiExcerpt name used in the MultiExcerpt-Include macro
With 3-D Secure 2.x a lot of additional data were required (e.g. browser-information, billing/shipping-address, account-info, ...) to improve authentication processing. To handle these information the JSON-objects have been put in place to handle such data. To indicate that these data are used the MsgVer has been implemented.
The page DEWORK:.Wording vDokumentation was not found -- Please check/update the page name used in the MultiExcerpt-Include macro Message-Version. Zulässige Werte:
Wert
Beschreibung
2.0
Mit 3-D Secure 2.x wurde eine Vielzahl zusätzlicher Daten (Browser-Information, Rechnungs-/Versand-Adresse, ...) erforderlich, um den Authentifizierungs-Prozess zu optimieren. Um diese Informationen zu handhaben, wurden die JSON-Objekte eingeführt. Der Parameter MsgVer zeigt an, dass diese Daten verwendet werden.
In case the authentication process included a cardholder challenge additional information about the challenge result will be provided.
Falls der Authentisierungsprozess eine Challenge des Karteninhabers enthalten hat, werden zusätzliche Informationen über das Ergebnis der Challenge bereitgestellt
Pseudo Card Number: Random number generated by which represents a genuine credit card number. The pseudo card number (PCN) starts with 0 and the last 3 digits correspond to those of the real card number. The PCN can be used like a genuine card number for authorisation, capture and credits.
PCNr is a response value from and is sent as CCNr in Request or part of card EN-JSON
Browser Payment Response
Additionally the JSON formatted data elements as listed below are transferred in the HTTP response body to the cardholder browser. Please note that the data elements (i.e. MID, Len, Data) are base64 encoded.
Merchants are supposed to forward these data elements to their server for decryption and mapping agianst the payment notification. Based on the payment results the merchant server may deliver an appropriate response to the cardholder browser (e.g. success page).