SubscriptionBridge: recurring billing and subscription management system - Documentation

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Managing a Subscription: switching from Trial to Full ======

===== Trial to Full: what it means =====

Imagine you subscribe to an e-mail marketing service, which offers a free trial period during which you can only send a message to 25 recipients (e.g. the [[http://www.getmailup.com|MailUp e-mail marketing system]] does exactly that). The trial might last 30 days or more, but you might be ready to commit to using the service after just a few days of testing it. In that scenario, you want to stop the trial, start the subscription, and have access to the "full" array of features that it will offer.

Similarly, imagine you decide to try out an online magazine that offers a free trial during which you can only access 5 articles a day. You like what you see, and want to read the rest of the articles. In this scenario too, you want to be able to end the trial, switch your account to a paying account, and have access to the "full" set of articles that the online magazine offers to its subscribers.

In these and many other scenarios you are switching from a **Trial** account to one that offers you **Full** access to all of the features and services that the merchant provides to its customers. As you might have guessed by now, that's why - in SubscriptionBridge - we refer to this feature as "//switching from Trial to Full//".

===== Who can switch from Trial to Full =====

  * **Customers** can switch from Trial to Full from the SubscriptionBridge Customer Center. A link to this "action" is included in the e-mail that they receive when they originally sign up for the product/service.
  * **Merchants** can trigger the switch from the subscription summary page in the Merchant Center.

===== What happens when a subscription is switched from Trial to Full =====

Some of the behaviors change depending on the payment gateway used.

The following always happens, regardless of the payment gateway used:

  * The subscription is updated in the SubscriptionBridge database
  * [[notifications_list#subscription-status-switched|E-mail notifications]] are sent to both the merchant and the customer
  * A [[notifications_list_callbackurl#subscription-status-switched|Silent Post is posted to the Callback URL]] (if one has been specified for the //Store//)

==== Authorize.Net: delayed payment issue ====

The following happens when a subscription is switched from //Trial to Full// on a store that uses [[payment-gateways:authorize.net|Authorize.Net]] as the payment gateway.

  * **The initial subscription is cancelled** (invisibly to the customer). \\ __Technical Note__: this is due to the fact that the subscription start date cannot be edited once a payment has been completed, and Authorize.Net completes a payment even if there is a free trial. In that scenario, Authorize.Net completes a "payment" for the $0.00 amount, no transaction ID is recorded, and an error message that says "Settlement Error" is shown in the list of //Completed Payments// for the subscription (this is current as of April 2010).
  * **A new subscription is started** with today's date as the start date. \\ The rest of the subscription details remain the same as the initial subscription, unless additional //Features// were added by the customer on the same day in which the subscription was changed from Trial to Full. In that scenario, the subscription amount will reflect the additional Feature prices.
  * **No payment is processed is real time**, but rather when the recurring payments are processed by the Automated Recurring Billing system (typically around 2 AM PST). This means that - depending on when the switch from trial to full is performed - there could be several hours during which payment has not been received. See the following notes for more on this.

Since there is no real-time payment processed when the subscription is switched from Trial to Full, it is up to you how to react to the various events that might follow. Specifically:

  * You may or may not want to turn on additional services when you receive the e-mail notification (or Silent Post). Some business may decide to wait until payment has been confirmed, others may opt to immediately give access to the full set of features provided by the subscription.
  * You will receive an additional notification when the first payment processes later that day (typically around 2 AM PST). At that time:
    * If you had already given access to additional features/services, and the payment fails, you can turn those features/services off
    * If you had not provided access, and the payment is successful, you can now give access to those features/services knowing that the customer is a paying customer.

==== PayPal ====

The following happens when a subscription is switched from //Trial to Full// on a store that uses [[payment-gateways:paypal|PayPal]] as the payment gateway.

  * **The initial subscription is updated** to reflect the new start date
  * **The payment is processed is real time** (in most cases). In our tests, there were some cases in which a payment was not processed immediately, but rather with some delay. We are unsure was to why. 

This means that - unlike with Authorize.Net - there should not be a delay between the switch from Trial to Full and the first subscription payment:

  * Both [[merchant_guide:notifications_list|e-mail notifications]] (status change and first payment) will be sent virtually at the same time.
  * Both [[merchant_guide:notifications_list_callbackurl|Silent Posts]] (if a Callback URL was specified for the Store) will be sent virtually at the same time.

Since the two "events" happen at the same time, you should wait until the second one happens successfully (first subscription payment made) before performing any action on the subscription (i.e. activating "full" features/services).