We've found that using Accept.js (JSON flavor) works just fine for single transactions. Reccing transactions, however, present a problem.
We initially had our recurring transaction "start date" set to the same day as the initial transaction, hoping that the first chage would happen immedlately when people signed themselves up. However, we noticed that that first charge always failed, though the second one, a month later, alwyas succeeded.
Our guess was that there might be some delay with setting up the customer profile, so maybe the profile was not ready yet for the first attempt to bill the card, whereas 30 days later it was ready.
So, we changed our "start-date" for the recurring billing cycle to one day later, thinking this would give the AuthNet system a day to adjust. The first transaction still failed.
We then changed the start date to be two days later, wondering how slow the AuthNet system was at creating profiles, but still no luck.
Now we have a theory that perhaps this is by design - that the first recurring transaction will never succeed.
Is there any way to ensure that these initial transactions complete successfully, or is the only way to start a monthly recurring billing cycle to make a separate one-time transaction for the same amount, at the same time?
04-23-2019 06:07 PM
Hi @jenlampton
Please confirm I understand your issue;
Is that correct?
Richard
04-24-2019 06:10 PM
Yes, that's correct.
The creation of the customer profile succeeds immediately, but the first attempt at recurring charge fails. That first failure happens whether the charge is scheduled for the same day, the next day (tommorrow) and also 2 days later. In all cases, the next charge a month later (and all subsequent charges) succeeds.
I'm looking into doing two transactions at once:
1) single one-time payment for recurring amount + create customer profile
2) create recurring subscription for that customer profile.
I'm worried though, that if I do this and this bug gets fixed my customers will start being double-billed the first month.
04-24-2019 06:16 PM - edited 04-24-2019 06:18 PM
If this is for your production account, please open a support case and ask for escalation. If you provide the case # here, we can also push it forward. Your use case should work.
However, since ARB does not currently support an immediate first payment. If that is your requirement, I might consider swithcing to your alternative solution. It validates the card details immediately, creates a customer profile and then you can use the customer profile to create a subscription.
Richard
04-24-2019 06:30 PM
> If this is for your production account
It is.
> please open a support case and ask for escalation.
Where do I do that? (I do not have access to the AuthNet account as I am only the developer - not the account owner. Do I need that?)
> ARB does not currently support an immediate first payment.
It doesn't have to be immediate, the next day is fine. Is that's supported?
> It validates the card details immediately, creates a customer profile and then you can use the customer profile to create a subscription.
I'm doing this already:
1) submitting the CC details via JS to validate the card detials, then
--> 2) getting a payment nonce if the info is valid, then
3) submitting the nonce as opaqueData via ARBCreateSubscriptionRequest to create the customer profile and subscription at the same time.
The new approach would be:
1) submitting the CC details via JS to validate the card detials, then
--> 2) getting a payment nonce if the info is valid, then
3) submitting the nonce as opaqueData via createCustomerProfileRequest (and also a createCustomerPaymentProfileRequest?)
--> 4) getting a customerProfileId if the profile was successful
5) submitting the customerProfileId via ARBCreateSubscriptionRequest to create the subscription
Looking over the code again, I now see `trialOccurrences` has a value of 1. I would bet anything that is what's causing the first credit card charge to fail. I'm going to change this to 0 and test, if this fixes everything I will not need answers to my other questions above (in bold).
04-24-2019 07:32 PM - edited 04-24-2019 07:44 PM
I've looked into the recommended approach, and it seems unnecessarily complex. If setting up a single transaction is three steps, why can't a recurring transaction also be three steps?
This is especailly frustrating because it's the EXACT same customer data in both cases. But for some reason, the exact same fields need to be split up into separate API calls for recurring transactions?
This seems like a design flaw with the API, and it's tripping up lots of developers:
https://community.developer.authorize.net/t5/Integration-and-Testing/Invalid-OTS-Token/td-p/61522
Everyone has the same instinct. First, make it work for the simpler single-transaction. Once that's working, adapt that process for the more complex recurring-transaction. If the recuring transaction worklfow is completely different, all the code (and time!) spent developing the first soltion can't be leveraged for the second.
04-24-2019 08:24 PM
Back to the point: I've reset `trialOccurrences` back to zero, and am trying to test. It works great on my local site, while connecting to the sandbox server.
On the production server, with a live account, I'm getting the same E00114: Invalid OTS Token error as everyone else, so I'm going through each of those gazillion forum topics and trying every recommended work-around I can find. Still no luck.
There's a chance all my recurring transactions are set up just fine in the AuthNet system. (Some of the reports of this error say that everything still works.)
Unfortunately, I'll need to wait until business hours tomorrow until someone can log in to AuthNet and check for me. (They have also asked AuthNet if there is a way I can get my own login with access to the data - but I told them not to share the password with me because, well, duh.)
04-24-2019 10:26 PM