no usable examples? about omnipay-authorizenet HOT 9 CLOSED

Unfortunately it's up to the gateway maintainer to add gateway specific documentation. We have a goal of adding better documentation to each gateway in the docblocks but it doesn't get added with the flick of a magic wand. @judgej is the maintainer of this package so I'm leaving that to him.

A good reference for how to do the basic Omnipay functions is in the docblocks of the omnipay-paypal package, in the REST gateway. The Stripe gateway also has extensive examples in the docblocks which include creating the card token and submitting payment. The process to do that is the same for most gateways.

from omnipay-authorizenet.

I've certainly got this on my list of TODOs (including some PRs here) but real life is kind of drowning me at the moment, so I'm getting a bit behind.

In the meantime, I can share code and details here in this thread, and we can use that to feed into better documentation. First question: which gateway are you using? AIM, CIM, DPM or SIM? How far through have you got with this? What framework are you using, and does that include any libraries to help manage the OmniPay settings (such as https://github.com/ignited/laravel-omnipay)? We'll go through setting this all up, step-by-step, and learn what is missing from the documentation.

from omnipay-authorizenet.

Hello,
could we start with the simpler use case say SIM explained like you did in your article about DPM (which by the way is really good but unfinished)

So let me rephrase: could you please finish your article on DPM and then write one on SIM in the same way? :)

Thank you

from omnipay-authorizenet.

Yes, unfinished, tell me about it :-(

SIM is a good place to start. Check out what I've written (with help, of course) for PAYONE and Sage Pay. Is that how you would envisage how the examples would look? There is a find line to tread: we don't want to be repeating too much OmniPay stuff across multiple gateway drivers, but we do want the examples to be fairly complete. Each gateway will have its foibles and peculiarities, which need to be explained IMO, because we want people to get up and running quickly, without the need to read through a hundred pages of documentation from the gateway provider to work out just what they really need to know.

My mum is in hospital at the moment, so my input may be sporadic, but I'll do what I can and other users can help to fill in the gaps.

from omnipay-authorizenet.

Hey Jason, sorry to hear about your mum. I am really not in a hurry and family first so please just take your time.
What you did for PAYONE and sagepay is fine, anything like that would be helpful.

Do you have plans to integrate the new accept.js code for Authorize? It makes it work a bit like Stripe and reduces the requirements for PCI complicance.

from omnipay-authorizenet.

Thanks, appreciated :-)

As for accept.js, that is a hard one. I am not sure that a unified or standard way to handle the JS front ends really exists yet in OmniPay, so it's all a bit adhoc until we have collectively learnt more about what they have in common. Some features would probably include:

• URLs to gateway JS that needs to be included.
• Helpers to build forms (providing the hidden from field data, an perhaps placeholder data for fields the user must enter).
• A 100% backend implementation of the JS front end for higher PCI apps and testing.
• Backend "complete" and "notification" messages to recognise the data supplied by a JS front end, including picking up on any errors that may have been generated.
• Anything else?

I've tried to include all this with PAYONE, tried to steer away from generating any html in the driver (just the data to create the html), but I could not find any other drivers with clear conventions to follow.

from omnipay-authorizenet.

Thanks, appreciated :-)

As for accept.js, that is a hard one. I am not sure that a unified or standard way to handle the JS front ends really exists yet in OmniPay, so it's all a bit adhoc until we have collectively learnt more about what they have in common. Some features would probably include:

• URLs to gateway JS that needs to be included.
• Helpers to build forms (providing the hidden from field data, an perhaps placeholder data for fields the user must enter).
• A 100% backend implementation of the JS front end for higher PCI apps and testing.
• Backend "complete" and "notification" messages to recognise the data supplied by a JS front end, including picking up on any errors that may have been generated.
• Anything else?

I've tried to include all this with PAYONE, tried to steer away from generating any html in the driver (just the data to create the html), but I could not find any other drivers with clear conventions to follow.

from omnipay-authorizenet.

For Accept.js support I'd just expect a gateway that takes in the nonce generated by the javascript, and creates transactions and what not from that. Form generation and handling isn't really something omnipay drivers tend to do (the ones I've used, anyway).

from omnipay-authorizenet.

I'm going to close this, as examples are slowly being added to the README. More would be welcome, but it's an ongoing process.

from omnipay-authorizenet.