SOAP and Fluid Token vs mandatory CC/PAN fields

mr_al — Sun, 24 Mar 2024 02:04:44 GMT

Hi all - this one is doing my head in so would appreciate some pointers. Here is the short version:

1. Wanting to submit a simple sale/payment via a web app using Google Pay (and eventually Apple Pay)

2. Have generated the Google Pay token OK, converted this to Base64 and added it into paymentInformation->fluidData->value field

3. All the other mandatory fields are provided

4. BUT the call to ->runTransaction will REJECT if we don't have the full 'card' details (i.e. PAN/account number, expiry month and date) included in the payload.

5. This is contrary to logic, as that's the whole idea of having the tokenised card information provided by Google (or Apple)

6. And yes, processingInformation->paymentSolution is set to "012"

7. Same symptoms using the php-sdk client.

Anyone figured out a root cause for this sort of behaviour, and what the magic configuration is to get Cybersource's gateway to realise it is a legit call with a legit Google Pay token, and thus it should NOT go looking for full PAN and all the trimmings?

thanks in advance,

mr_al

Re: SOAP and Fluid Token vs mandatory CC/PAN fields

mr_al — Sun, 24 Mar 2024 12:55:27 GMT

OK…figured it out, but not without trawling deep into the PHP class structure. Here’s what I found:

This is an example using the Cybersource REST Api Samples, which can be found on Github here: https://github.com/CyberSource/cybersource-rest-samples-php

Preconditions / One time setup
Use the Business Dashboard Key Management Screen [ https://ubctest.cybersource.com/ebc2/app/PaymentConfiguration/KeyManagement] to create a new REST-Shared Secret api key and secret.
Keep these handy, along with your Merchant ID (i.e. thiscompany_12345678) found at the top of the dashboard screen.
Going to assume that you all know how to download these sample PHPs to your server.
Edit the ./Resources/ExternalConfiguration.php file and change these three lines to have the same value as the Shared Secret api and secret, and your merchant id, that you generated in step ‘a’:

$this->merchantID = "testrest";

$this->apiKeyID = "08c94330-f618-42a3-b09d-e1e43be5efda";

$this->secretKey = "yBJxy6LjM2TmcPGu+GaJrHtkke25fPpUX+UY6/L/1tE=";

…and save it.

Other pre-condition – I’m also going to assume that you can generate a Google Pay Token via your app. We’ll come back to this later.

Making a payment test program

In the same library of files, navigate down to ./Samples/Payments/Payments
Copy the file DigitalPaymentGooglePay.php to new file name, say, testPay.php
Edit the testPay.php file, and make the following changes:

aa. Change the value of

$clientReferenceInformationArr = [

"code" => "xxxx"

];

…and replace ‘xxxx’ with an easily remembered string (so you know it is “your” transaction that has been tested.). I use a random order number such as “1234-001”.

Make sure this statement says this (it should already...012 means 'Google Pay'):

$processingInformationArr = [

"capture" => $capture,

"paymentSolution" => "012"

];

cc. Immediately under that statement INSERT the following three statements like so:

$paymentInformationFluidDataSet = [

"value" => "yyy…yyy=="

];

$paymentInformationFluidData = new CyberSource\Model\Ptsv2paymentsPaymentInformationFluidData($paymentInformationFluidDataSet);

$paymentInformationArr = [

"fluidData" => $paymentInformationFluidData

];

** where “yyy…yyy==” is your loooooong Base64 encoded Google Pay token mentioned in step “1e” above”

dd. DELETE or comment out the lines that read:

$paymentInformationTokenizedCardArr = [

"number" => "4111111111111111",

"expirationMonth" => "12",

"expirationYear" => "2020",

"cryptogram" => "EHuWW9PiBkWvqE5juRwDzAUFBAk=",

"transactionType" => "1"

];

…and…

$paymentInformationTokenizedCard = new CyberSource\Model\Ptsv2paymentsPaymentInformationTokenizedCard($paymentInformationTokenizedCardArr);

…and…

$paymentInformationArr = [

"tokenizedCard" => $paymentInformationTokenizedCard

];

…as these populate the paymentInformation object with the plain old PAN and expiry date, which we do not need as its encoded in the token.

ee. Save it

ff. run it (i.e. php testPay.php)

gg.Celebrate

hh. Take a deep breath and take a long run up to do similarly for Apple Pay.

topic Re: SOAP and Fluid Token vs mandatory CC/PAN fields in cybersource APIs

SOAP and Fluid Token vs mandatory CC/PAN fields

Re: SOAP and Fluid Token vs mandatory CC/PAN fields