Can anyone explain WHY GravityForms handles ARB this way?
I understand it's important to verify the credit-card in real-time, at the moment the ARB Subscription is created. But doing that with an AIM Capture transaction, and actually charging the initial payment via AIM (instead of ARB), causes two problems:
1) This one initial payment will be separate from all the subsequent recurring transactions for the Subscription (in a different area of the AuthNet Merchant Interface, i think). And these must then be tied together, by some shared field, like an Invoice Number, Customer ID, or Email Address.
2) Some ARB Subscription data will seem wrong. For example, a subscription purchased today (Feb 12), should have a Start Date of Feb 12, but instead ARB shows Mar 12. That's not really correct. GF shifts the Start Date because we already got the initial payment, so we don't want to charge for it twice. It might also confuse the number of occurrences. But this could be confusing for the merchant (and customer, if there's a client-portal on the site).
Instead of these problems, why not just use the AIM Auth-Only transaction, to verify the credit-card at the moment the ARB Subscription is created. Then the first charge will be done -- by ARB, not by AIM -- the very next day (at 2pm PST).
Just wondering about the benefit of the GravityForms approach, so I can explain the problems to my client.
Posted 10 years ago on Wednesday February 13, 2013 | Permalink