Help : SCA and PHP Payment Form

Hi All,

Banging my head against a wall here on implementing the SCA verification in the Payment Form.

Using Sandbox, and attempting to verify with the test nonce set as "cnon:card-nonce-requires-verification. Using test card to trigger what I would think would be an authentication step.

Basic javascript is:

cardNonceResponseReceived: function(errors, nonce, cardData, billingContact, shippingContact) {

    document.getElementById('card-nonce').value = nonce;
		total = document.getElementById('total');

  	const verificationDetails = {
		amount: total,
		intent: "CHARGE",  //Allowed values: "CHARGE", "STORE"
		locationId : locationId,
		currencyCode: 'GBP',
		billingContact: {
			familyName: document.getElementById('familyName').value,
			givenName: document.getElementById('givenName').value,
			country: document.getElementById('country').value,
			city: document.getElementById('city').value,
    }
  };
  try {
	nonce= 'cnon:card-nonce-requires-verification';
    paymentForm.verifyBuyer( nonce, verificationDetails,
          function callback(err,verification) {
              if (err == null) {
              document.getElementById('buyerVerification-token').value = verification;
             }
         });
   document.getElementById('nonce-form').submit();

Everything seems to proceed until the submit is triggered. Nothing is added to the hidden field byerVerification-token (unsure if I’m meant to pass this at all?).

then I receive the following errors in console:

1: [Error] Failed to load resource: the server responded with a status of 400 () https://connect.squareupsandbox.com/v2/analytics/verifications

2: XMLHttpRequest cannot load https://pci-connect.squareupsandbox.com/v2/v?version=ca1c99ac2e due to access control checks. (repeated 3 times)

Then the form ‘submits’ to the ‘process.php’ page, where it tells me it’s failed.

There’s no verification step, and the transaction fails on the following page (obviously)

Can anyone point me in the direction fo where I may look to fix?

Ben

Hi @benjamieson welcome to the forums!

The test nonces aren’t really meant to be used like that; they would be used directly with CreatePayment call, and bypass the Square Payment Form altogether. Try using the Visa EU test card (4310 0000 0020 1019) by directly typing in the form to generate it as a nonce instead and see if that works. If it doesn’t, please provide your Square app id and I’ll see if I can uncover anything in our logs.

Thanks so much - I’m getting somewhere - managing to pass the Verification token through to my process page, but here I’m stuck again.

How do I then pass that to CreatePaymentRequest

The only args I can see it taking are the nonce, a uniqueID, and the charge details.

I currently have (pre SCA):

$payments_api = $client->getPaymentsApi();

$money = new Money();
$money->setAmount($_POST['amount']);
$money->setCurrency('GBP');

$create_payment_request = new CreatePaymentRequest($nonce, uniqid(), $money);

Where do I place the v.token in there?

Ben

Are you using one of our SDKs? The CreatePayment endpoint definitely takes a verification_token argument as can be seen in this documentation.

Edit: if you’re using one of our SDKs, it’s possible you’re using an older version before SCA existed?

Using the PHP SDK yes.

I’ve installed with composer, and updated along the way, so presume I’m using the latest version?

I updated the above, but so far I have:

$payments_api = $client->getPaymentsApi();

$money = new Money();
$money->setAmount($_POST['amount']);
$money->setCurrency('GBP');

$create_payment_request = new CreatePaymentRequest($nonce, uniqid(), $money);

This was fine pre-SCA as nothing else was needed, but I need to know where in that I pass the v.token?

Sorry if I’m an idiot - photographer by trade!

Not an idiot at all, no worries :slight_smile: . So per the PHP SDK docs, there should also be a verificationToken field in the CreatePaymentRequest. You should be able to do something like:

$create_payment_request = new CreatePaymentRequest($nonce, uniqid(), $money);
$create_payment_request->setVerificationToken($verificationToken);
...

To be clear, according to the code, sourceId, idempotencyKey, and amountMoney are all required constructor parameters, but there’s several additional fields you can set as you can see in the first link I provided above.

I figured it just before you posted!

Thanks for setting my sails in the right direction!

1 Like

OK, one more question, as I have SCA working now.

How do I create a customer at the same time - I see there’s a reference to INSTANT_PROFILE in the docs, but I am unsure how to utilise this within the createPayment?

Do I need to do a separate request for this, and if so, how would I tie to the payment just processed?

Currently, I have:

$payments_api = $client->getPaymentsApi();

$money = new Money();
$money->setAmount(number_format($_POST['amount'] * 100, 0,'.',''));
$money->setCurrency('GBP');

$create_payment_request = new CreatePaymentRequest($nonce, uniqid(), $money);

if ($_POST['buyerVerification-token'] !=''):
	$create_payment_request->setVerificationToken($_POST['buyerVerification-token']);
endif;

$create_payment_request->setBuyerEmailAddress($_POST['email']); //unsure where this is used?

try {
  $response = $payments_api->createPayment($create_payment_request);

    ...

Any pointers on this one?

Essentially, you would want to use the Customers API to actually create the customer first. After you create a customer, you’ll have the customer_id, in which case you can pass into the CreatePayment request to attach the customer to the payment.

Instant profiles can be created automatically if we have any information on our side about the customer. For instance, if card “1234” was used at a Square merchant previously, and they opted for text receipts, then technically we have that information on our side. So, if the card is used again (and no customer_id is passed), then we can attempt to recognize that this customer actually exists, and create an instant profile. I definitely would not recommend relying on instant profiles, as more often than not very little information will actually be provided (it’s possible for an instant profile to have no information, because the receipt text/email information is not public, so we wouldn’t actually share it with any merchant).