Recurring Transactions

SWREG offers to ability to completely automate weekly, monthly, quarterly, semi-annually, or annual recurring/subscription orders. The recurring order functionality offers the ability to have multiple products in the same order with different recurring timeframes. Subscriptions apply to credit card orders only.


Reports can be processed within the main reporting area of your store. To limit the reports to only master or child orders you will select those options under "Order Type".


The most common setup method is a recurring profile. To setup up a profile you first need to create the product that will recur under the "Create/Edit Products" area. Next, from the main menu, follow these steps:

The recurring functionality has the ability to a "trial" period where we will check the credit card and won't bill them until the certain timeframe has passed. To set this up, a product for $0 needs to be created and assigned to the recurring profile with all the recurrence rules. A price variance will need to be on the profile for the amount to be billed after the initial profile frequency has passed. When that product is ordered we will check the card with a $0.01 authorization, and if successful, will process the order. SWREG will then charge the customer the variance amount on the first recurrence and going forward.

To note: The system will only process a product for $0 if it is a recurring product that has a profile assigned to it.

There is also the option to set up an order to recur after the order is placed. To do this, go to "Recurrence Profiles" and then input the order number into the "Manual Order Setup". Then, you will set the same specifications for that specific order.

Finally, there is the ability to pay any affiliates for recurring or subscription orders. To select this option, login to the SWREG control panel and select "Configuration." In the "Setting" area, "Affiliate Tracking," make your selection accordingly.


To Stop a Master Order:

To Retry a Failed Child Order:

To See Details on an Enabled Master Order:

You can also see on the order details all child orders associated with that master order and their status.

Altering a Recurring Order through our API

API Usage

The API provides a way for you to alter some characteristics of a recurring order. You can integrate the API within your systems or customized deliverables to your customer. To use this API you will need to be able to POST data to a URL and parse the results. It is recommended that you use standard toolsets available for your platform or application to ensure all data is encoded and decoded in a standard and compliant manner. The API is designed to conform to RESTful design principles.

General integration details

Enable/Disable a Master Order

This method provides a way for you to disable or enable a recurring master order, as long as you have the order number. An example is listed below, under "Integration Examples".

To disable an order, send a POST request to the URL listed above, with the value disabled=1.

To enable an order, send a POST request to the URL listed above, with the value disabled=0.

Change the next billing date of an order

This method provides a way for you to change the next billing date of a recurring order, as long as you have the order number. The order must already be in a processed state for the date to be changed.

To use, send a POST request to the URL listed above, with the value newdate=YYYY-MM-DD. Replace YYYY-MM-DD with the desired date. For example, to set the date to June 1, 2020, send newdate=2020-06-01.

Retry a failed order

This method provides a way for you to retry a failed recurring order. If an order resulted in a declined or rejected card, you are able to attempt an additional transaction against that child order. Note that this functionality will not allow you to retry an order for reasons other than a processing failure.

To use, send a POST request to the URL listed above, with /retry appended to the end, replacing %ORDER_NO% with the master order number. Child order numbers will not be accepted. A proper retry URL will look like this, before replacing with a proper order number:

Integration Examples:


This is the most portable method as it can be used with any programming language that can execute an external program and use the input. It does force you to manually do some parts of the process however so it should be considered secondary to any native library that allows you to execute HTTP POSTs.

% curl -i --user %SHOP_ID%:%PASSWORD% --data disabled=0 \

This outputs a response that should look something like this:

HTTP/1.1 200 OK
Date: Wed, 17 Jun 2009 13:51:52 GMT
Server: Apache/2.2.14 (Unix) mod_fastcgi/2.4.6
Vary: Content-Type,Authorization
Content-Length: 32
X-Catalyst: 5.800007
Connection: close
Content-Type: application/x-www-form-urlencoded


You will need to parse and evaluate the output (most importantly the status code from the first line and any messages in the body).


This provides a richer interface (response parsing, etc) but does require knowledge of Perl programming (see the LWP::UserAgent documentation).


use strict;
use warnings;

use LWP::UserAgent;

my $ua = LWP::UserAgent->new();
my $response = $ua->post(
    {disabled => 1}
if ($response->is_success) {
    # handle success here
    print $response->content;
} else {
    # handle errors here...
    print $response->as_string;

Other Languages

Any modern programming language should provide a native HTTP toolset that should allow you to do similar things to the above.

Email Notifications to Vendors

Every morning we will send out batch emails with any orders that failed during the attempt to complete. The email will contain the order number, reason for failure, and the master order number for each child order.

SWREG offers a paypal alternative, affordable ecommerce, payment processing, ecommerce solution, and an online software store with the ability to sell shareware.