automatic renewals with Authorize.net

Is silent post the ONLY way Authorize.net is able to report back a payment was made to CBSubs or can CBsubs get that info from Authorize another way?

AdvisorProducts wrote: Is silent post the ONLY way Authorize.net is able to report back a payment was made to CBSubs or can CBsubs get that info from Authorize another way?

For automated re-occuring payments, yes.

For single payments, no

And for the first immediate payment of auto-reoccuring payments, no but only for the very first that doesn't work with silent posts, but with AIM.

I just talked to Authorize.net again.
They said that the issue is that they are making changes that may prevent the silent post url from reporting back properly. They also said they are phasing out silent post entirely in the future and said to configure a webhook. I was told I could use the silent post url that CBSubs shows in the url field for the webbhook. When I used that url, it failed and the reason is that Authorize.net will not allow queries in the url and the default CBSubs silent post url has queries in it. So I need to know from you if there is a way to either change the silent post url for CBSubs so there are no queries, or do you have a way specifically to set webhooks in the CBSubs for Authorize.net?

AdvisorProducts wrote: I just talked to Authorize.net again.
They said that the issue is that they are making changes that may prevent the silent post url from reporting back properly. They also said they are phasing out silent post entirely in the future and said to configure a webhook. I was told I could use the silent post url that CBSubs shows in the url field for the webbhook. When I used that url, it failed and the reason is that Authorize.net will not allow queries in the url and the default CBSubs silent post url has queries in it. So I need to know from you if there is a way to either change the silent post url for CBSubs so there are no queries, or do you have a way specifically to set webhooks in the CBSubs for Authorize.net?

This lack of backward compatibility and repeatedly sudden API changes without any understanding on the requirement of solution providers are one of the reasons that we do not recommend authorize.net anymore. See the "deprecated" anouncement at top of authorize.net settings in the latest CBSubs release. As already said above/previous page, we will not continue to support authorize.net payment method when they change again their APIs, because we find such reckless users-business damaging behavior not acceptable for our users. And it looks like it's going to happen soon or has happened already.

Thus we highly recommend choosing a different supported payment services provider with proven customer-friendly and business-savy very long term compatibility track records (e.g. Stripe, Paypal, Ingenico/Ogone), and move rather sooner than later.

I both understand and share your frustration with Authorize.net. However I think it's important you acknowledge the position you are putting your customers in when you say you are no longer going to support Authorize.net. Many of us have been using your software and Authorize.net for years. Your suggestion to 'simply switch processors' is anything but simple and will create a giant mess for many of us if we take your advice. What happens in the future if the processor we switch to happens to upset you? Then we're just out of luck and have to switch again? No thanks. I've seen comments in your release updates that Stripe requires webhooks and CBsubs can do it. Authorize.net has now added webhooks so why can't you add webhooks to Authorize.net to keep your loyal customers from having to switch to another processor? We don't blame you when a processor like Authorize.net changes something and breaks the functionality of your software - but we do trust you'll work to make the needed updates. Does that sound so unreasonable?

So just to confirm, are you saying you absolutely won't be updating your software to work with Authorize.net's new webhooks so ARB's can report back the payment info? And that the only 2 choices you are giving your loyal customers are to switch to another processor or switch to one of your competitors that do plan to keep working with Authorize.net?

It's not just a matter of Authorize.net upsetting us. They're changing their API and providing no backwards compatibility. This breaks thousands of integrations requiring a complete rewrite of the integration (it's not just a matter of adding webhooks, which are not backwards compatible with silent post). They provided no advanced notice of this to us either through our developer accounts. That makes it extremely difficult to maintain this gateway. We do not have the time, resources, or man power to keep rewriting gateways every time they feel like redoing their API and providing no backwards compatibility.

As for changing gateways as long as you aren't using recurring payments your users will never notice and it'll be a simple transition for you. If you are using recurring payments then it of course becomes more difficult since those recurring payments won't exist on the next gateway.

Additionally we do not recommend users to use payment gateways that accept payments directly through your server. This requires very strict PCI compliance. It is safer for your users and easier for you to use a gateway that transmits payment information directly to the gateway (e.g. Stripe does this very well).

The problem is with no backwards compatibility it would mean a stop-work on literally everything else for this, which isn't fair to all of our other customers waiting for various releases. I suppose my question is is Authorize.net mandatory for your business?