Not an issue, but a question / feature request - Auto-Billing?

[scottblair]

Does the authorize.net aspect of Omnipay support Authorize.net's auto-billing / recurring billing features?

[judgej]

It only supports the common functions at the moment - authorisation, payments, capture, but not much else. There are no plans to extend that, but that does not mean it can't or won't be supported if someone wants (or has a need) to put the time in.

[brianmc]

We'd be happy to help out with adding some of that functionality. I'll take a closer look at the project and see where/when we might be able to help out.

[delatbabel]

Have a look at some of the other gateways that implement some kind of recurring billing feature (e.g. PayPal REST, Stripe, etc) and make sure that you use roughly the same method names. Recurring billing specifically is outside of the scope of Omnipay but there are a few gateways that have added it.

[judgej]

Been looking at the way Authorize.Net is going, and it seems that they are in the process of deprecating all their current integration-oriented APIs. Instead, they are pulling all the functionality into a merchant-oriented API, based largely on the original AIM API.

I think if starting again here, it would be good to follow the way they have structured the new API, with focus on groups of functions for:

• Transactions
• Customer profiles
• Recurring billing <-- this is the one you are asking about
• Reporting

So in this case rather than, say, firing up an AIM gateway object and doing recurring billing through it, you would instantiate a "recurring billing" gateway object and do all the recurring billing stuff you may need to do through that. You may also need to instantiate customer profiles and transactions objects to work in conjunction with that (e.g. a recurring bill would need a customer profile to work from).

I think also now that the API fully supports JSON, that should be used as it is easier to handle (the XML objects can be a bit cumbersome at times).

[judgej]

And using something like dot notation to access the received data would be so much easier than having to check for missing elements constantly:

https://github.com/dflydev/dflydev-dot-access-data

[judgej]

I'm not quite sure they have the JSON API quite right yet. The documentation gives examples with fragments in similar to this:

            "lineItems": {
                "lineItem": {
                    "itemId": "1",
                    "name": "vase",
                    "description": "Cannes logo",
                    "quantity": "18",
                    "unitPrice": "45.00"
                }
            },

That's okay for XML, where multiple lineItem elements can be child elements of the lineItems element. But this does not work in JSON, so I guess the documentation is incorrect and this should be an array, perhaps something like this:

            "lineItems": [
                {
                    "itemId": "1",
                    "name": "vase",
                    "description": "Cannes logo",
                    "quantity": "18",
                    "unitPrice": "45.00"
                }
            ],

It's not a biggy, but it does kind of highlight that the kinks are not all out of the new API yet.

[brianmc]

You're spot-on, the JSON flavour of our XML API can seem "just not quite right". Depending on your timelines our new REST API (Same Authorize.Net API, same organization, XML not going away) will really be a "native JSON" API and should not have these issues. I can send you an email with some more details and timelines.

[judgej]

Yes, the (estimated) time line for the REST API would be great, with any thoughts on what the API will look like.