-
Notifications
You must be signed in to change notification settings - Fork 91
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
Using the XML API for AIM gateway #6
Conversation
… attribute requires the presence of itemId, name, quantity, unitPrice which is not properly documented in AuthorizeNet's API documentation.
PR updated to support refunds through AIM as well. |
… valid CC info. AuthorizetNet only requires last 4 digits of the credit card for refund transactions
Fix refunds for authorize.net
+1 It would be great to implement the Bank Account stuff I just implemented in #8 as well! |
…before making the authorize net requests.
…yment profile for a give customer profile. If that call also results in duplicate, then get the customer profile containing all its payment profiles. Then get the payment profile id matching the last4 in our original request. Once this is done, use the customer profile id, payment profile id, and update the card details. (It is possible that last4 matches but the expiry dates change). After updation of the payment profile, return the response.
…erence will contain customer profile id and customer payment profile id, as these are enough for making a transaction
…AIM and CIM Application needs to pass parameter "duplicateWindow=x" which when not null will be sent as extra options with the request.
XOL-2533 Adding extraOptions payload to request XML
Fix travis issues
…profile limit Normally if a duplicate payment profile exists, Authorize.net will return Error code E00039. But if the customer has the maximum number of payment profiles (10), then AUthorize.net will return E00042. So whenever we receive E00042 we need to check the existing payment profile list to see if there is a duplicate profile.
CS-137 Cannot process payment for customer that has 10 saved cards and is using existing saved credit card
* 'master' of github.com:xola/authorizenet: CS-137 Set constants for the profile response codes CS-137 Add tests for verification of duplicate payment profile logic CS-137 Use PHP 5.3 array() syntax so tests pass CS-137 Look for duplicate payment profiles even if you reach maximum profile limit Normally if a duplicate payment profile exists, Authorize.net will return Error code E00039. But if the customer has the maximum number of payment profiles (10), then AUthorize.net will return E00042. So whenever we receive E00042 we need to check the existing payment profile list to see if there is a duplicate profile.
XOL-2776 Make CVV optional
XOL-2788 Void an Authorize.net transaction if it has not been settled
This has been hanging around for a while, and does have a lot of hard work in it. The other gateway types (DPM and SIM) extend from AIM, so we need to make sure this change is not going to break those. Has anybody here got any experience of AIM? |
@judgej Thanks for picking this back up. I'm actually in the process of making another substantial overhaul. You may have noticed that this PR also brings in support for CIM (ability to save customer profiles and credit cards). Originally, AIM and CIM were quite different, but now Auth.Net has done some pretty good consolidation of the two. They both now share common endpoints and payload for the basic actions (auth, capture, refund, void) -- which was not the case before. So I'm trying to refactor the code such that those actions have shared logic. I'd suggest holding off on this PR for another week or so; I'm pretty close to finishing the refactoring.
What's been done here should not affect DPM or SIM. The abstract classes that they extended from have not been altered in content; just renamed. |
Awsome :-) |
Moves the AIM gateway over to the new and improved XML API.
I tried to leave most unit tests untouched to ensure the least amount of potential breakage, but some had to be tweaked since this was a significant overhaul.
As part of this change, the SIM classes have been completely decoupled from the AIM classes; they used to share some functionality earlier, but that's no longer possible since the endpoints and data format are now very different.