AuthorizeNetApi_Api, AuthorizeNet_AIM, AuthorizeNet_CIM

[xopher]

I'm trying to make payments with saved payment profiles (not the one-time nonce (Opaque Data) provided by Accept.js).

I'm first using AuthorizeNet_CIM->createCard() with the Opaque Data from my checkout form:

CIM returns: paymentProfile

• customerProfileId
• customerPaymentProfileId

These values are stored permanently, and then I need to process two separate payments (which is why I can't use the Opaque Data as that is a one-time token).

What fields must I submit along with amount, currency, and transactionId to get the AuthorizeNetApi_Api->purchase() method to complete a successful transaction?

[xopher]

I've reviewed the Authorize.net API Documentation and it looks like a PROFILE object is passed instead of a CARD object with customerProfileId and paymentProfile->paymentProfileId. I've tried passing these in Omnipay without any luck.

Am I really the first Omnipay/AuthorizeNetApi_Api user to try and perform payments with stored payment details? I feel like I'm missing something obvious, but scratching my head as to where it is documented.

Thanks for any help.

[judgej]

It's a big API that tries to do a lot of things that is often handled by the host application (nobody wants to lock their application workflow to a single payment gateway, well I don't anyway). So yes, you may well be one of a few. The documentation is massive and just about impossible to track changes and fixes they make to it.

Longer term, I'm hoping Authorize.Net will publish some OpenAPI descriptions for their API, then we can move to auto-generated and validated code, and hopefully avoid many problems related to untried paths through the code.

Anyway - every bit of help appreciated, so if you have any PRs, they will be very useful.

[xopher]

Thanks for your reply Jason, and all the work you’ve put in to these libraries. If Omnipay can not make payments with saved payment methods, I’ve definitely selected the wrong package. All of the core Omnipay documentation (https://omnipay.thephpleague.com/api/token-billing/) and online discussion alludes to this being possible. I wouldn’t know where to begin with a PR (apologies), it took me weeks to figure out that AIM is essentially about to be deprecated, API compatible with AIM but is the future, but that it still lacks basic functionality included in CIM which is also scheduled to be EOLed. I honestly think the best thing for anyone forced to use Authorize.net is to use the API directly. I’m pretty sure it’s more work to navigate Omnipay’s documentation, example code, and feature set than Authorize.net’s SDK.

[judgej]

The way I have tackled this package is like this:

Looking through the API docs, I created a bunch of models that cover as much of the API feateres as I could. That's all in academe/authorizenet-objects. That was laborious and lots of work. The documentation was changing all the time, still is, so those models will constantly need updating.

Ideally I would like to auto-generate those models from an OpenAPI description. I did that for Starling Bank Payments from scratch in less than an hour this morning: https://github.com/academe/starling-payments-api-sdk/tree/master/api/src/Model That's my ideal way to go, but I have not yet found any OpenAPI description files for Authorize.Net that work. Once I do, rebuilding the models will be a push-button affair and could even be automated.

Now, those models will probably support what you need. You can use them with or without Omnipay if you want to go to the API directly.

Now Omnipay is a wrapper for those models. It does things the standard Omnipay way, but uses the models underneath to construct the API requests and parse the responses. Those features may support what you need, or may need expanding. It may work, or may have some bugs that need sorting. If a feature you want is described in the Omnipay docs, then this package really should support it, and needs fixing if it doesn't. If the feature you want is not what Omnipay does out of the box for payment gateways in general, then that's fine - it may only need a new method to be added with a few lines of code to map data to the correct models - most of the Omnipay gateways handle some feature that is specific to the gateway they support.

I'm just not sure where we are now.