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.
====== Using SubscriptionBridge in a testing environment ======

===== Overview =====

This article provides information on how to "test" the process of buying and managing a subscription with SubscriptionBridge.

How and what to test can vary depending on the payment gateway that you have associated with your SubscriptionBridge-based store. So the rest of the article is divided into sections that are specific to each payment system. The natural way to test SubscriptionBridge is by using the Test Payment Gateway, so we'll start there.

===== Test Payment Gateway =====

SubscriptionBridge includes a [[payment-gateways:test|Test Gateway]] that allows you to test a variety of features without having to sign up for a "live" recurring payment system.

  * Take your time and familiarize with SubscriptionBridge without having to pay any payment gateway fees
  * Research the various recurring payment systems that SubscriptionBridge supports while still being able to test the system
  * [[payment-gateways:test|More information on the Test Gateway]]

The main limitation of using the Test Gateway is that it does not allow you to test recurring payments, but rather only the user-triggered payments (e.g. purchasing a new subscription, adding a feature, paying an outstanding balance, etc.).

===== Authorize.Net =====

==== No "sandbox" ====

The [[payment-gateways:authorize.net|Authorize.Net Automated Recurring Billing]] (ARB) system does not have a testing (or "sandbox") environment. Authorize.Net Advanced Integration Method (AIM) does, but not the Recurring Billing system. So there is no way to create a "test" subscription and then have it process recurring payments in a //test mode//.

==== Real transactions, but no "captures" ====

However, you can test the system in a live environment without actually charging the credit cards used in the tests. This is because when a transaction is processed by the ARB system, it is //passed// to the main Authorize.Net virtual terminal and it appears under //Unsettled Transactions//, awaiting settlement. Recurring payments are processed at around 2 AM PST, and those same payments are not captured until the afternoon (PST). So there are several hours in which the payments remain unsettled and can be voided before they settled.

For instance, this means that you can do the following:

  * Purchase a subscription via the built-in SubscriptionBridge shopping cart, using a real credit card
  * An ARB subscription will be setup in Authorize.net
  * ARB transactions are processed around 2 AM PST. Those transactions then appear under Unsettled Transactions until the time they are settled later that day (typically late afternoon, PST). So you have several hours in which you can:
    * Locate the transaction under Unsettled Transactions
    * Click on the transaction ID
    * Click on the VOID button to void it. \\ Note that voided transaction may still appear in your credit card statement for a few days as the corresponding amount had been pre-authorized and was awaiting settlement. They will automatically disappear after a few days (this can take up to 2 weeks, according to Authorize.Net).

By using this approach, you are testing the system in a fully "live" environment. When recurring payments are processed, information will be posted to SubscriptionBridge via the [:authorize.net#add-silent-post-url|Silent Post URL]. The only difference compared to what you will do with "real" transactions consists in the voiding of the payment before it is settled.

==== Create a short subscription to test ==== 

To test the system and simulate different scenarios, setup a short subscription (e.g. a subscription with a weekly payment interval and a week-long free trial, for example). You will then see SubscriptionBridge go through a series of "events" associated with the subscription (E.g. trial expiration reminder, subscription payment notifications, etc.). Note that Authorize.Net requires that the billing period be weekly or longer (i.e. you cannot setup a daily subscription, although that would be useful for testing purposes).

===== Using PayPal in a testing environment =====

PayPal has a testing ("sandbox") environment: you can [[https://developer.paypal.com/cgi-bin/devscr?cmd=_signup-run|sign up for a PayPal sandbox account]] at any time. __The PayPal Sandbox mimics exactly the live PayPal system__. To test SubscriptionBridge with PayPal, follow these instructions.

==== Create a PayPal Sandbox Account ====

  * [[https://developer.paypal.com/cgi-bin/devscr?cmd=_signup-run|Sign up for a PayPal sandbox account]]
  * Once you have activated your sandbox account, you will need to create a seller account within it (from your sandbox account, you can create fictitious accounts for both buyers and sellers, so you can test both sides)

==== Create a PayPal business account in the Sandbox ====

  * Log into the PayPal sandbox
  * Create a new account manually (there is an option to "//Create Manually//")
  * Follow the instructions on the screen to create the account

Note that PayPal will add to the e-mail address that you enter some additional characters when the account is actually created. Don't worry, that's just the way it works. Messages sent to that e-mail account can be seen by clicking on "Test E-mail" in the left-side navigation.

==== Configure your PayPal business test account ====

  * Log into the PayPal sandbox
  * Select //Test Accounts// from the left-side navigation
  * Now that you have a business (seller) account within the PayPal Sandbox, select it and click on "//Enter Sandbox Test Site//"
  * The user name is the e-mail associated with the PayPal Sandbox seller account (//the one with the extra, funny characters mentioned above//)
  * The password is the one that was created at the time you created the seller account. If you forgot it, you can request to create a new one. Just remember that e-mails sent to your seller account can be seen only by clicking on "Test E-mail" in the left-side navigation of the sandbox portal.

This Sandbox account works just like any regular PayPal business account. You will need to obtain the API Credentials and set the Instant Payment Notification settings just like you would do with a regular PayPal business account.

  * **API credentials**: you can request API credentials as described [[:payment-gateways:paypal#obtaining-your-api-credentials|here]], or you can simply click on API Credentials in the left-side navigation of the sandbox portal, as shown below. The same Sandbox API credentials will be provided to you. {{:merchant_guide:sbpaypal_sandbox.png|PayPal sandbox}}
  * **Instant Payment Notification**: follow the [[:payment-gateways:paypal#configuring-instant-payment-notification|same instructions]] use to set Instant Payment Notification settings for a regular PayPal business account.

==== Use the PayPal sandbox account in SubscriptionBridge ====

In SubscriptionBridge, as your payment gateway, select the PayPal payment system that you wish to use (Express Checkout or Website Payments Pro) and enter the credentials that you have just obtained from the sandbox. 

You can now use SubscriptionBridge with PayPal in a sandbox (testing) environment.

<note important>NOTE: to successfully submit orders using the PayPal sandbox, you must use a buyer user created using your sandbox account, and __you must be signed into your PayPal sandbox account__ at the time you place the order. Otherwise, you will receive an error.</note>