Our customers are ordering products which have recurring payments. For example a video course costs initially 50$ and then 10$ per month. Customers pay over our plattform but the statistics over purchases should be visible in infusionsoft.
This means we need to create a recurring order over the API. We are currently using the XML RPC API.
I read the article Creating order via XML-RPC about the flow of creating a recurring order and ran into a problem.
First I call the DataService.add Endpoint to create a new entry in the RecurringOrder table. This API-Call returns the orderId.
This OrderId is then used in the InvoiceService.createInvoiceForRecurring API-Endpoint to create the invoice. Problem is that I get a 200 Response and the id of the invoice is always 0.
I also don´t see the invoice in the Infusionsoft endpoint.
Does anyone has an Idea what we are doing wrong?
If there are Information missing, please feel free to request them, I can provide further details then.
So I think you’re trying to reinvent the wheel here.
the xml-rpc has methods for handling all of this that you don’t have to go to the underlying xml endpoints to work with. Since you’re having an issue with doing that, the normal methods are already working as they should so why not, at least in this case, just use them?
I checked the endpoint InvoiceService.addRecurringOrder and there is some information required that we cannot provide. For example, we cannot provide a creditCardId because we are handling our payments on our platform and only want to send the information about already billed and paid orders.
So are you saying that recurring orders are designed to be used if you want to have the payment processed by Infusionsoft? And this would mean there is no need to create a recurring order, we only need to send the processed orders/payments to infusionsoft.
Yes, Infusionsoft would expect the Card Details to be present. I never have seen it done like you have mentioned before, but it would not work. Infusionsoft would do the charge and create the Invoices afterwards. You could technically use a Sandbox Merchant Account and use Test Card Data to simulate the Recurring Order creation, but that would get messy when connecting it to real Contacts. What happens in situations if the Card was declined, etc.
It is better off to let your Payment Provider handle all the Charging and Recurring Orders. All you need to do is to transfer the payment information across into Infusionsoft.
If your Platform does not do Recurring Orders, then could you not create a Scheduled Job that runs say the 1st of Every Month to do the Charing instead. I do not know what you are using to handle your payments.