How to process recurring transactions with Authorize.Net
I'm trying to process recurring payments through Authorize.Net with the following requirements:
Payment processing would be initiated by us
Customer would enter card data on first transaction only. We would bill the card monthly, with potentially different amounts but would not have the card data present.
Want to re开发者_StackOverflow社区quire the CVV on first transaction. If it succeeds, when we bill the card monthly, CVV would not be required for transactions later.
We do not want to stored sensitive information like credit card data. User would have option later to specify a different card or update their profile (this can be done by SOAP, XML or any commonly available method)
This would include echeck transactions
Effectively, we're trying to create a similar experience as Amazon, where you enter the card data once. When you buy in the future, you only select your profile/(card and shipping address) you want to use and the payment goes through, without entering in card or CVV again. The only difference is, we're initiating the payments in the future as our services are subscription based.
My initial thought was using CIM. However, due to the 3rd requirement, CIM may not work for this as it doesn't store the CVV. What's the best route to achieve the result we're after?
You do not need to use AIM for the first payment. Just use CIM and send the CVV code with the payment profile. Authorize.NET will not store the CVV code, but, it will verify it once and remember the card is verified for charges against the payment profile. We've been using this method for over a year and have had no issues.
You would need to use a combination of the Advanced Integration Method (AIM) and Customer Information Manager (CIM) API for this. You would use AIM to process the first payment which would allow you to verify that the CVV number provided is valid. If it is then you can set up a payment profile on CIM for them.
Authorize.net lets you configure the Card Code Validation Settings through the web interface as follows:
Select the conditions for which the Payment Gateway should reject a transaction when
the Card Code submitted does not match the value on file with the customer's credit
card company.
Reject Transaction If Card Code value...
_ Does NOT Match (N)
_ Is NOT Processed (P)
_ Should be on card, but is not indicated (S)
_ Issuer is not certified or has not provided encryption key (U)
Card Code Verification (like Address Verification) only actually occurs if a card code is submitted. Enabling the Card Code Verification filters will not affect transactions submitted without a card code.
There is also a separate page called 'Payment Form - Fields' where you can specify which fields can be viewed, edited, and required on the payment form. If you check off that CVV2 is required on this form, it will also require CVV2 to be specified every time you use AIM/CIM. Note, it seems more sane to just implement this requirement in your code, if you want it, rather than checking the box on Authorize.net and then trying to debug the errors.
If you keep the CVV2 on the 'Payment Form - Fields' as not required, if you have a saved Payment Profile, you can submit a new Transaction Request on the saved PaymentID without any CVV2 and it won't be rejected.
Now some sites I'm sure you've seen will show the saved card to the user (masked of course), and ask them to type in the CVV2 again -- just the CVV2, without re-entering a card number.
If you want to actually do the re-validation of just the CVV2 on an existing Payment Profile in Authorize.NET CIM, you can't use updateCustomerPaymentProfileRequest because it needs the card number.
What you do is inside the TransactionRequest there is a profileTransAuthCaptureType object, which takes the ProfileID and PaymentID. It also has a field for cardCode where you can put the CVV2! This lets you re-validate the CVV2 without asking for the whole card number / expiration date over again. In this case, even if 'Is NOT Processed' is checked, and CVV2 is marked as required on your 'Payment Form - Fields' you will not get a reject.
There's method to the madness, but it sure is complicated since you control all the settings, and they need to be in sync in multiple places for it to work how you want.
精彩评论