A subscription functions the same whether a merchant creates, updates, and cancels a subscription in the Merchant Interface, or the merchant uses the Authorize.Net API. When a merchant creates a subscription in the Merchant Interface, he or she enters all required information into the Create New ARB Subscription form. When the merchant submits the information, the Subscription Confirmation page returns a message to the merchant indicating whether or not the subscription was created successfully. The subscription ID assigned for a successfully created subscription is also displayed.
The Authorize.Net API accomplishes the same functions through an API call and subsequent response. Whether a subscription is created in the Merchant Interface or through the API, the results are the same. For descriptions and code samples of the API elements used for subscriptions, see the API Reference Guide.
Subscriptions do not process transactions in real time. Creating a subscription transaction successfully does not guarantee that subscription payments will process through your account successfully. Subscription transactions process at approximately 2:00 a.m. PST on scheduled payment dates. Therefore, the first scheduled transaction is not sent to the customer’s bank for authorization until approximately 2:00 a.m. PST on the start date that you specify when you create the subscription in your account. If you create a subscription with a start date that equals the creation date, the first scheduled payment does not process until after 2:00 a.m. the following day. If you wish to validate your customer’s payment information before creating their subscription in your account, use one of the real-time transaction processing methods available through the Authorize.Net API.
You can create, update, and cancel a subscription. Subscriptions contain the following information.
The subscription ID is generated by Authorize.Net and is used to manage a subscription. It is also stored with any transaction generated by that subscription so that you can better track it.
Start Date — this date is the date of the first transaction. Credit card data is verified as part of this first transaction, and not before.
Interval Units — intervals define the number of total charges to be made and on what schedule; for example, weekly or monthly.
Trial Period — for a trial period, you can specify an amount and then charge a different amount for the remainder of the subscription.
Credit Card — customers’ encrypted credit card information is stored on Authorize.Net’s secure servers. Note that the card code is not supported because PCI-DSS security standards require that it not be stored.
eCheck — customers’ banking information is stored on Authorize.Net’s secure servers.
Customer information includes:
TIP: The first transaction conducted after a subscription is created or edited is processed like any other transaction and is subject to the Address Verification settings of your account. Subsequent transactions are flagged as recurring when we send them to the processor. In most cases, the processor does not verify addresses for transactions flagged as recurring.
Subscriptions with a monthly interval whose payments begin on the 31st of the month occur on the last day of every month.
Here are a few things to keep in mind:
The subscription start date (subscription.paymentSchedule.startDate) may be updated only if no successful payments have been completed.
The subscription interval information (subscription.paymentSchedule.interval.length and subscription.paymentSchedule.interval.unit) may not be updated.
The number of trial occurrences (subscription.paymentSchedule.trialOccurrences) may be updated only if the subscription has not yet begun or is still in the trial period.
When the start date is the 31st, and the interval is monthly, the billing date is the last day of each month (even when the month does not have 31 days). All other fields are optional.