Below is documentation on interfacing to BluePay's library software:
BluePay 2.0 POST Method for Rebilling Updates
For automated integration. This interface is NOT for Posting directly from a web form!
The URL of this interface is currently:
PLEASE NOTE: This URL may change in the future. In integrating your system, please remember
to make the URL a parameter you can easily change. If you are coding a shopping cart, please
make the URL a parameter the merchant can easily set.
Expected input format is that of a standard HTTPS POST. All parameters are uri-encoded in the
body of the request, for example:
### BEGIN REQUEST EXAMPLE ###
### END REQUEST EXAMPLE ###
Expected output is that of a standard HTTPS response. The HTTP Status will be '200' for a successfully-
processed request and '400' for an error. All response parameters are uri-encoded in
the body of the response, for example:
### BEGIN RESPONSE EXAMPLE ###
HTTP/1.1 200 OK
Date: Tue, 07 Dec 2004 17:31:12 GMT
Content-Type: text/html; charset=ISO-8859-1
Expires: Tue, 07 Dec 2004 17:31:12 GMT
### END RESPONSE EXAMPLE ###
Input Parameters are:
ACCOUNT_ID = Your 12-digit BluePay 2.0 Account ID
USER_ID = Optional. Your 12-digit BluePay 2.0 User ID
TAMPER_PROOF_SEAL = An MD5 hash of your Secret Key and a few transaction parameters, as below.
REBILL_ID = Required. The 12-digit ID of the Rebilling to modify/view
TRANS_TYPE = Optional. GET or SET (defaults to SET)
If set to GET, then you are only required to send the ACCOUNT_ID, TAMPER_PROOF_SEAL, and REBILL_ID.
If "SET" then you must also send at least one field, below, to set the value of:
TEMPLATE_ID = Optional and dangerous - selects a new transaction ID to act as the template for
this rebilling sequence.
NEXT_DATE = Set the next rebill date to this date.
REB_EXPR = Set the rebilling expression to this expression.
REB_CYCLES = Set the number of remaining rebilling cycles to this number.
REB_AMOUNT = Set the regular rebilling amount to this amount.
NEXT_AMOUNT = Set the *next* rebilling only to this amount; all other rebilling’s will continue at the regular (REB_AMOUNT) amount.
STATUS = Set the status of this rebilling. Valid statuses at the time of writing are:
The TAMPER_PROOF_SEAL is an MD5 checksum of your SECRET KEY and a few transaction parameters. We use an
MD5 simply to avoid sending the SECREY KEY over the wire, and we include some of the transaction parameters
simply as a convenient source of "random" padding. The TAMPER_PROOF_SEAL is currently calculated as follows:
md5(SECRET KEY + ACCOUNT_ID + TRANS_TYPE + REBILL_ID)
where '+' indicates string concatenation and undefined fields are concatenated as '' (null string)
Your md5 function must return a hex-encoded md5 checksum. If you do not know your SECRET KEY, please contact
Output Parameters are returned for GET and SET transactions - if you perform a SET, the returned parameters should
reflect your changes:
REBILL_ID = The 12-digit ID specifying this rebilling.
ACCOUNT_ID = The 12-digit ID of the account owning this rebilling.
USER_ID = The 12-digit ID of the user owning this rebilling.
TEMPLATE_ID= The 12-digit ID of the template for this rebilling.
STATUS = The current status of the rebilling
CREATION_DATE = The date the rebilling sequence was originally created.
NEXT_DATE = The next day this rebilling will be run.
LAST_DATE = The last day this rebilling was run.
SCHED_EXPR = The current rebilling expression for this rebilling
CYCLES_REMAIN = The number of remaining rebilling cycles for this rebilling.
REB_AMOUNT = the regular amount this rebilling will charge the customer.
NEXT_AMOUNT = The amount this rebilling will charge on the next billing only.
Output HTTP status code is 200 for a successfully processed request.
Output HTTP status code is 400 for an error request.
View Our Payment Modules
855-812-5191 to get access to the applicable integration modules.