-
-
Notifications
You must be signed in to change notification settings - Fork 929
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Authorize.Net CIM gateway #51
Conversation
@adrianmacneil it's will be good if you create a new tag after merge, I'll add a changelog file after tagging |
Does this need to be a separate gateway? Can't you just add createCard/updateCard/deleteCard methods to the AIMGateway? |
It should be separeated cause it's standalone gate in Authorize, called CIM. Only CIM support saving card and Authorize take additional fee. |
Yeah, but you use it in conjunction with AIM and SIM right, with the same credentials? If you configured a shopping cart with AIM and also wanted it to optionally store cards, you would use the same API credentials. Just the same as with Stripe when you store a card for token billing. |
There is is a two case, right and not right, if you use a AIM teoretical you can CRUD card/profile, and it's a no problem, But you can't bill on surch card cause authorize/purchase etc. request is different then for AIM or SIM. So for do it right you should switch from AIM or SIM to CIM, or handle both, AIM or SIM for direct capture, and CIM for capture saved customer credit cards |
I'm no see a sense to copy all calls from CIMGateway to the AIM or SIM cause we should copy tottaly all calls |
But seems we can add a call CIM CRUD or Capture from AIM or SIM without additional gate configuration, just as additional options, but stay CIM standalone casue for it usign no need AIM or SIM |
Ok I just looked into this more. We need to update the AIM gateway to use the new XML API, and at the same time integrate CIM, so that if the developer sends calls CIM shouldn't be a separate gateway, because it is essentially a fancy name for the token billing parts of Authorize.net. Omnipay's design goal is to abstract the differences between gateways, so the classes should be structured around our own API and not Authorize.net's bizarre product lineup. The developer using Omnipay does care that CIM is a separate product/addon. They should be able to just do:
The requirement is that this can be used in a shopping cart which can use generic calls on every gateway and not need to know the differences between each gateway. |
Ok, get your point, will update AIM with CIM integration |
@pilot are you currently looking at switching AIM to XML? I was looking to implement credit/refunds in AIM but I'll hold out on doing it if you are currently working on the gateway. |
Yep currently on switching AIM to use xml, plan to implement during a week On Thu, May 2, 2013 at 10:47 AM, Christian Freear
|
Did this move any further? |
@mathewpeterson I hope to refactor it in near feature |
@pilot @adrianmacneil There is a new PR for switching the AIM gateway to the XML API thephpleague/omnipay-authorizenet#6 |
The CIM Gateway is now supported on xola/authorizenet and there's a PR for it too thephpleague/omnipay-authorizenet#6 |
New function; addSupportedBrand.
No description provided.