Support for Accept.js

[felixmaier1989]

Following the discussion on #41

[judgej]

Quick question: if the front-end form puts the tokenized card into POST data opaqueDataDescriptor and opaqueDataValue, does that mean the application does not need to handle it explicitly at the back end? Are those the field names the official SDK suggests?

I've not tried this, but if the payment fails for some other reason (e.g. invalid postcode or something) then can this tokenized card be used again (if so, how many times), or does the end user need to completely re-enter their credit card details again (a personal pain point in many stores)? I think this will effect whether the application needs to be capturing the tokenized card details or not, in the session, in case they need to be reused after a other-details validation failure.

Looks great. I'll aim to get it merged later today.

[felixmaier1989]

I dont fully understand your first question. Here is the code I run in the back end:

/**
 * @var \Omnipay\AuthorizeNet\AIMGateway $gateway
 */
$gateway = Omnipay\Omnipay::create('\Omnipay\AuthorizeNet\AIMGateway');

$gateway->setApiLoginId(...);
$gateway->setTransactionKey(...);

$request = $gateway->purchase([
    'notifyUrl' => 'htts://www.perdu.com',
    'amount' => $amount,
]);

$request->setOpaqueDataDescriptor($_POST['data_descriptor']);
$request->setOpaqueDataValue($_POST['data_value']);

$response = $request->send();

if ($response->isSuccessful()) {
    // ...

}

As for the field names, I didnt check them against the SDK. Taking a look at it:

https://github.com/AuthorizeNet/sample-code-php/search?utf8=%E2%9C%93&q=opaque
https://github.com/AuthorizeNet/sdk-php/blob/9d24edc675362b6349983205b8288d178fa0c469/lib/net/authorize/api/contract/v1/OpaqueDataType.php

Seems like the relevant approach would be to handle an OpaqueDataType object made of two properties dataDescriptor and dataValue.

I dont have any strong opinion about it. Let me know what you decide, I'll change it.

[judgej]

The request class, used to POST data to the gateway, is looking at GET data in putting its data together. That makes an assumption about what is happening in the environment in which the request object is put together. I was just clarifying that was intentional and that I understood why it was working that way.

Actually, looking again, it should probably be removed since it uses GET and not even POST:

https://github.com/thephpleague/omnipay-authorizenet/pull/77/files#diff-3197c271405074529f9f6b7b308a0546R171

If I understand correctly, that could potentially be injected by an end user just by adding GET parameters to the merchant site credit card form POST URL, and without any input validation. Best leave full control in the merchant application like in your example.

[judgej]

In other words, when a payment request is created, what it contains will be affected by GET parameters in the URL of the page that constructs the payment request, and that cannot be prevented by the application without explicitly resetting those two values, which any site NOT wanting to use Accepy.JS would not be doing.

[felixmaier1989]

Ok I get you. I just removed that. That originally was in Mark's snippet and I assumed this was right.

Regarding the variable naming, any thoughts?

[judgej]

Thanks, I think that is safer.

The variable name looks good to me. It is named very specifically for Authorize.Net, and we can provide a more generic wrapper or mapping later if and when we develop any common approach across the various gateways.

[Mark-H]

I was missing the setter in my code, which is why I needed to fetch it directly from the $_GET.

[Mark-H]

Looks like it works as expected here 👍 Just had to fix my javascript to use the right names.

[judgej]

All merged - thank you. If you could confirm the master branch works for you, I'll try to get a release done today. I've added a few notes to the README too - anything to add or correct, just shout PR :-)

[felixmaier1989]

I tested it and it works fine for me! Let us know about the release. Thank you.

[judgej]

Thanks, I'll work on a release ASAP. It looks like there are a number of other PRs coming related to reporting and refunds (the transactionReference is a little messy) so it would be good to get a new baseline.