Pin: Add authorize & capture support #29
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Wirecard supports the notion of "Recurring Transactions" by allowing the merchant to provide a reference to an earlier transaction (the GuWID) rather than a credit card. A reusable reference (GuWID) can be obtained by sending a purchase or authorization transaction with the element "RECURRING_TRANSACTION/Type" set to "Initial". Subsequent transactions can then use the GuWID in place of a credit card by setting "RECURRING_TRANSACTION/Type" to "Repeated". This implementation of card store utilizes a Wirecard "Authorization Check" (a Preauthorization that is automatically reversed). It defaults to a check amount of "100" (i.e. $1.00) but this can be overriden. In order to reuse the stored reference, the +authorization+ from the response should be saved by application code. Already present was the ability to run a purchase transaction using a GuWID. This commit adds the ability to do the same for an authorization transaction. Note: any transaction can generate a reusable GuWID reference by setting the option :recurring to "Initial". This functionality already existed but is now documented.
Thanks to @moklett who had a major part in helping me put this together. We don't want to require billing_address for #purchase because it doesn't require one itself in the API. Added tests to remote for purchases / etc with and without billing address. During all of this we also discovered that #store requires a billing address with at LEAST country and name. From the eWAY folks this is for legacy API reasons.
The original implementation of protocol v7 called this field "acquirer" (without the "s"), which matches some of the current Quickpay documentation but contradicts other parts. We learned via Quickpay support (through debug of a chargify.com merchant issue) that the field in the request is called "acquirers", representing a list of acquirers to attempt, ordered by preference (i.e. `acquirers=nets,teller`). The response will contain a field called "acquirer" which conveys which acquirer was actually used in the transaction. Before this change, attempting to set the old `:acquirer` option would result in an MD5check hash mismatch, since the ActiveMerchant code would use the `acquirer` field in the calculation, but Quickpay would not. After this change, both ActiveMerchant and Quickpay agree on the MD5check hash when the `:acquirers` option is set, and the `:acquirers` option has the intended effect of setting the preferred acquirers for the transaction. (The latter can be negative-tested by setting the value for acquirers to an invalid acquirer value and observing the error response: "Error in field: acquirers") Despite the change to the option key (`acquirer` to `acquirers`), I feel this is a safe, backwards compatible change since attempting to set the old option could never result in a successful transaction - the MD5check hash mismatch error would always occur. Note: I have asked Quickpay that they update all of their v7 documentation to reflect the correct field name. At this time I am still waiting for those changes to happen.
While working with Quickpay in production mode, it was discovered that "amount" and "currency" are required values for store (subscribe) operations in the v7 API. Without it, subscribe operations complain with "Error in request parameters". This is confirmed by their documentation, which currently states that both "amount" and "currency" are required: http://doc.quickpay.net/api/messagetypes.html#index2h2 This commit makes the change such that only the subscribe parameters for v7 (and up) are changed. New unit tests were added to prove the correct parameters are now being sent, and all existing remote tests were run and are passing.
Amex does not support authorization_check, so an authorization is done instead.
In order to use the same card number when updating a payment profile (a "partial update"), you must send the last-four digits of the card as the CreditCard#number, masked (e.g. `XXXX11234`). This change checks if the card number being passed into `add_credit_card` is 4 digits. If it is, we assume a partial update is being attempted, and we mask this value in the way Auth.Net expects. See http://www.authorize.net/support/CIM_XML_guide.pdf, page 70, under `cardNumber`.
Amex should be american express
Fixes eway tests
Adds support for Braintree paypal
- Allow purchase to take a payment_id as well as a token - Use a Multiresponse to optionally tore and convert a token
PayMill Updates
…blue Adds application_id functionality to Braintree Blue
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Upstream updates for Pin:
Add authorize/capture and customer update to Pin Payments gateway
See https://github.com/Shopify/active_merchant/pull/1268