The display of the Segpay payment page is determined by how you request it. This document will show you how to set up your payment links (or “button codes”) to trigger different versions of the payment page. For example, you can:

• Pre-populate specific fields in the payment form, such as first/last name and email.
• Offer one, multiple, or all of your price points for a consumer to choose.
• Show languages other than English.
• Show currencies other than USD, EUR or GBP (for Europe-based merchants).
• Set up postback notifications to make sure the correct data is passed to you after events such as payment and cancellation.
• Offer existing consumers one-click payment (no need to re-enter card details) and/or instant-conversion (immediate access to full membership before a trial period ends).

 

Base URL

Go to the Segpay Merchant Portal – at mp.segpay.com - or the spreadsheet your Segpay rep gave you, and locate the button code from one of your payment profiles. This is your base URL for that payment profile. Here is an example: 

(Note that the x-eticketid value in the URL above is only an example.  It will be different in your base URL.)

Use that URL to request the base version of your payment page, which includes all of the price points and cross sell info for the website this package is assigned to.

Now let’s discuss how to change the display of the payment page, so you can customize it for different scenarios simply by adding parameters to your base URL.

 

Pre-populate Fields or Request Data

By adding parameters to the base URL, you can pass information from your site to the payment page, to pre-populate fields in the payment form, display links or text after the transaction, or to request that specific data be captured during payment and passed back to you when the transaction is complete.

 

Here are some examples:

Parameter	What it Sends/How to Use it
x-billname	The consumer’s First and Last name.   Get Request (append to base URL):   &x-billname=Joe+Segpay   Post Request:   <input type="hidden" name="x-billname" value="Joe Segpay ">   Payment page display:
x-billemail	The consumer’s email address.   Get Request (append to base URL):   &x-billemail=anyone%40abc.com   Post Request:   <input type="hidden" name="x-billemail" value="[email protected]">   Payment page display:
x-billaddr	The consumer’s street address (No longer a default field on payment page. Please ask your Segpay rep if you would like to display this field).   Get Request (append to base URL):   &x-billaddr=123+Fake+Street   Post Request:   <input type="hidden" name="x- billaddr" value="123 Fake Street">
x-billcity	The consumer’s city No longer a default field on payment page. Please ask your Segpay rep if you would like to display this field). Get Request (append to base URL):   &x-billcity=Las+Vegas   Post Request:   <input type="hidden" name="x- billcity" value="Las Vegas">
x-billstate	The consumer’s state/province/territory* No longer a default field on payment page. Please ask your Segpay rep if you would like to display this field).   *Ask your Segpay rep for list of valid entries. Here’s an example, using ND for North Dakota.   Get Request (append to base URL):   &x-billstate=ND   Post Request:   <input type="hidden" name="x- billstate" value="ND">
x-billzip	The consumer’s zip/postal code.   Get Request (append to base URL):   &x-billzip=12345   Post Request:   <input type="hidden" name="x-billzip" value="12345">   Payment page display:
x-billcntry	The consumer’s country.*   *Ask your Segpay rep for list of valid entries. Here’s one example, using US for the United States:   Get Request (append to base URL):   &x-billcntry=US   Post Request:   <input type="hidden" name="x-billcntry" value="US">   Payment page display:
merchantpartnerid	An affiliate partner that will link to your payment page to send referrals. Merchantpartnerid appears in transaction reports and helps both you and Segpay’s Risk Management team manage the transactions coming from your affiliate program. (Used for post back only; no display on payment page).   Get Request (append to base URL):   &merchantpartnerid=anyvalue   Post Request:   <input type="hidden" name="merchantpartnerid” value="anyvalue">
x-auth-link	Specify the link that displays for the consumer after an authorized transaction.   Get Request (append to base URL):   &x-auth-link=http%3A%2F%2Fwww.mywebsite%2Fmembersarea%2Findex.htm   Post Request:   <input type="hidden" name="x-auth-link" value="http://www.yoursite.com/members/Index.htm">   Payment page display:
x-auth-text	Combine with x-auth-link to specify text for the link that displays after an authorized transaction.   Get Request (append to base URL):     x-auth-link=http%3A%2F%2Fwww.mywebsite%2Fmembersarea%2Findex.htm&x-auth-text=CLICK+HERE+TO+SIGNIN+TO+THE+MEMBERS+AREA!   Post Request:   <input type="hidden" name=”x-auth-link” value=http://www.mywebsite/membersarea/index.htm” name="x-auth-text" value="CLICK HERE TO SIGNIN TO THE MEMBERS AREA!">   Payment page display:
x-decl-link	Specify the link that displays for the consumer after a declined transaction.   Get Request (append to base URL):   &x-decl-link=http%3A%2F%2Fwww.yoursite.com%2FLinkToOtherPaymentOptions   Post Request:   <input type="hidden" name="x-decl-link" value="http://www.yoursite.com/LinkToOtherPaymentOptions">   Payment page display:
x-decl-text	Combine with x-decl-link to specify text for the link that displays after a declined transaction.   Get Request (append to base URL):     &x-decl-link=http%3A%2F%2Fwww.yoursite.com%2FLinkToOtherPaymentOptions&x-decl-text=CLICK+HERE+TO+TRY+ADDITIONAL+PAYMENT+OPTIONS   Post Request:   <input type="hidden" name="x-decl-link" value=http://www.yoursite.com/LinkToOtherPaymentOptions name="x-decl-text" value=" CLICK HERE TO TRY ADDITIONAL PAYMENT OPTIONS">   Payment page display:
username	The consumer’s username.**   Get Request (append to base URL):   &username=anyvalue   Post Request:   <input type="hidden" name="username" value="anyvalue">
Password	The consumer’s password. **   Get Request (append to base URL):   &password=anyvalue   Post Request:   <input type="hidden" name="password" value="anyvalue">
CrossSaleOff	Choose whether the cross-sell options assigned to your payment package display on the payment page.   Get Request (append to base URL):   &CrossSaleOff=1 – Does not display cross sell.   &CrossSaleOff=0 (or simply exclude this parameter) – Displays the cross sell.
User-defined pass-through parameters. Examples:   memberID sessionID	Your own user-defined data.   You can pass your own user-defined data to Segpay (data that gets dynamically-generated by your system) using parameters such as memberID or sessionID. There is no limit to the number of user defined parameters you can create and send to Segpay. However, values are limited to 32 characters and cannot begin with a number.   User defined parameters are stored together in a field called USERDATA and are included in the transaction detail report on  mp.segpay.com and the Segpay Reporting Services (SRS) transaction reports.   Get Request (append to base URL):   &memberID=EnterMemberID &sessionID=XXXX     Example sending the following parameters:   * Remember that the x-eticketid values in the URLs below are only examples, and will be different in the version you are sending.   email address, zip code, username, password, memberID, an auth link with text and a declined link with text.   https://secure2.segpay.com/billing/poset.cgi?x-eticketid=162209:3097&x-billemail=anyone%40abc.com&x-billzip=12345&username=anyuser&password=anypassword&memberid=anymemberID&x-auth-link=http%3A%2F%2Fwww.yoursite.com%2Fmembers&x-auth-text=CLICK+HERE+TO+SIGNIN+TO+THE+MEMBERS+AREA!&x-decl-link= http%3A%2F%2Fwww.yoursite.com%2FLinkToOtherPaymentOptions&x-decl-text=CLICK+HERE+TO+TRY+ADDITIONAL+PAYMENT+OPTIONS   Post Request: <form method="post" action="https://secure2.segpay.com/billing/poset.cgi?x-eticketid=104855:1221"> <input type="hidden" name="x-billemail" value="[email protected] "> <input type="hidden" name="x-billzip" value="12345"> <input type="hidden" name="username" value="anyuser"> <input type="hidden" name="password" value="anypassword"> <input type="hidden" name="memberID" value="anymemberID"> <input type="hidden" name="x-auth-link" value=" http://www.yoursite.com/members"> <input type="hidden" name="x-auth-text" value="CLICK HERE TO SIGNIN TO THE MEMBERS AREA!"> <input type="hidden" name="x-decl-link" value="http://www.yoursite.com/ LinkToOtherPaymentOptions"> <input type="hidden" name="x-decl-text" value="CLICK HERE TO TRY ADDITIONAL PAYMENT OPTIONS"> <input type="submit" name="Submit" value="Join Now"></form>
REF parameters	Your own REF data.   You can define up to 10 REF values: REF1 - REF10. REF values are each stored in their own fields and reported separately from user-defined values.   REF values are encrypted, for added security, when stored in our database.   * Remember that the x-eticketid values in the URLs below are only examples, and will be different in the version you are sending. Get Request (append to base URL):   &REF2=   Example sending the following: email address, zip code, username, password, memberID, an auth link with text and a declined link with text.   https://secure2.segpay.com/billing/poset.cgi?x-eticketid=162209:3097&REF1=XXXX   Post Request:   <form method="post" action="https://secure2.segpay.com/billing/poset.cgi?x-eticketid=104855:1221"> <input type="hidden" name="REF1" value="XXXX "> </form>

 

** If you selected “Collect Username and Password” (or Password only) when creating your price points, these fields will display on the payment form and can be pre-populated using the parameters above. Otherwise login data can be passed to Segpay in the background. This is recommended if you assign logins to your consumers or if you let your consumers pick their own username or password on your site.

 

Customize How Prices are Displayed

Grab the base URL to one of your payment packages, and add or modify certain parameters in the URL to display the payment page in different ways. Here are some examples:

Let consumers choose from all of the different price points you assigned to a package.	Example request:   Note: This is the base URL assigned to your package. No parameters are added. Example result:
Let customers choose from a few of the price points you assigned to a package, but not all of them.	Example request: Note: Add &pplist= to the URL, followed by the IDs of each price point you want available on the page. Separate IDs with commas. The value after the colon represents the price point that will be selected by default for the consumer. (Find your price point IDs in the Merchant Portal. Select My Websites, then Price Points.) Example result: (Displays only the price points specified).
Show customers just one of the price points assigned to a package	Example request:   Note: Add &ppviewoption=2 to the URL. The value after the colon represents the price point that will display.   Example result: (Displays only the price point specified).
Allow price selection via radio buttons instead of dropdown list.	Example request:   Note: Add ppviewtype=2 to the URL.  Example result:
Display selection via radio buttons in conjunction with a limited price point list.	Example request: Note: Combine pplist with ppviewtype to display only certain price points, with radio button selection. Example result:

Show Languages Other than English

Payment pages are built with geo-targeting and will display by default according to the language setting in the consumer’s browser. However, you can force a payment page to display in a specific language, simply by adding a parameter to your base URL. 

Following are the languages you can use, and the parameters to append to your base URL to display them:

LANGUAGE	PARAMETER
Spanish	&paypagelanguage=ES
French	&paypagelanguage=FR
German	&paypagelanguage=DE
Greek	&paypagelanguage=EL
Italian	&paypagelanguage=IT
Japanese	&paypagelanguage=JA
Portuguese	&paypagelanguage=PT
Russian	&paypagelanguage=RU
Simplified Chinese	&paypagelanguage=ZS
Slovak	&paypagelanguage=SK
Slovenian	&paypagelanguage=SL
Traditional Chinese	&paypagelanguage=ZH
Dutch	&paypagelanguage=NL

Notes:

• The old language parameter Lang=NL (using Dutch as an example) still works, but is overridden by the consumer’s browser language.
• Consumers can choose the language themselves via dropdown list on the payment page:

 

 

Dynamic Multi-Currency (Europe-based Merchants)

Europe-based merchants can display pricing in currencies other than just USD, EUR or GBP (see list of supported currencies below). Contact Segpay technical support to set up Dynamic Multi Currency (DMC). Ask to be set up according to one of the first two settings below:

DMC SETTING	PAYMENT PAGE FEATURES
DMC with Base Currency	Prices are displayed in the currency you assigned when setting up the price point, Consumer can choose their local currency from a dropdown menu. You can pass the parameter DMCURRENCY to either hide the currency menu or force display of a different currency (see Supported Currencies list below). Example requests: * Remember that the x-eticketid values in the URLs below are only examples, and will be different in the version you are sending. No parameters specified; currency assigned in price point is displayed, consumer can change to local currency: https://secure2.segpay.com/billing/poset.cgi?x-eticketid=162209:3097   DMC turned off. Currency assigned in price point is displayed, consumer cannot change currency (menu is hidden). https://secure2.segpay.com/billing/poset.cgi?x-eticketid=162209:3097&dmcurrency=none   Currency displays in Hong Kong Dollars (HKD) per parameter passed in the URL; consumer can change to local currency: https://secure2.segpay.com/billing/poset.cgi?x-eticketid=162209:3097&dmcurrency=hkd
DMC with Geo-Targeting	Prices are displayed in local currency, based on the region of the consumer’s IP address. If Segpay doesn’t support the local currency in a given region, then currency will default to what you set up in the price point. Consumer can choose another currency from dropdown menu. You can pass the parameter DMCURRENCY to either hide the currency menu or force display of a different currency (see Supported Currencies list below). Example requests: * Remember that the x-eticketid values in the URLs below are only examples, and will be different in the version you are sending. No parameters; currency displayed is based on the region of the consumer’s IP address; consumer can change to local currency: https://secure2.segpay.com/billing/poset.cgi?x-eticketid=162209:3097   DMC turned off; Currency displayed is based on the region of the consumer’s IP address; consumer cannot change currency (menu is hidden). https://secure2.segpay.com/billing/poset.cgi?x-eticketid=162209:3097&dmcurrency=none   Currency displays in Hong Kong Dollars (HKD) per parameter passed in the URL; consumer can change it to local currency: https://secure2.segpay.com/billing/poset.cgi?x-eticketid=162209:3097&dmcurrency=hkd

 

With Dynamic Multi-Currency turned on, consumers can choose their local currency.

Supported Currencies:

Currency	PARAMETER
Australian Dollar	&DMCURRENCY=AUD
Canadian Dollar	&DMCURRENCY=CAD
Swiss Franc	&DMCURRENCY=CHF
Danish Krona	&DMCURRENCY=DKK
Hong Kong Dollar	&DMCURRENCY=HKD
Japanese Yen	&DMCURRENCY=JPY
Norwegian Krona	&DMCURRENCY=NOK
Swedish Krona	&DMCURRENCY=SEK
US Dollar	&DMCURRENCY=USD
Euro	&DMCURRENCY=EUR
British Pound	&DMCURRENCY=GBP
Russian Ruble	&DMCURRENCY=RUB
Indian Rupee	&DMCURRENCY=INR
Israeli Shekel	&DMCURRENCY=ILS
Czech Koruna	&DMCURRENCY=CZK

Note to Merchants: When viewing data about DMC transactions, amounts are reported in your base currencies. For example, if your base currency in a price point is USD, but a Canadian consumer changes to CAD and pays the CAD value, transaction reports will reflect the USD equivalent of that transaction.

Postback Notifications

A postback is when Segpay transfers data back to your system after certain events occur on our end. Now that you’ve set up your payment links with parameters specifying the data you want SegPay to capture during payment, set up your postbacks to specify how/which data is sent back to you after various events.

Types of Postbacks

There are two types of postbacks:

Postback Type	Definition
Member management	Triggered by events that affect a member’s subscription to your service. For example, a new username/password is created; or a member signs up for, or cancels, a service. These types of post backs include:   Inquiry: Triggered when SegPay collects a username and/or password during payment. The postback checks if the username already exists and, if so, defaults the username to the member’s email (please verify that your scripts support email addresses as usernames).   Enable: Triggered after an approved purchase where a username and/or password were collected. The postback is a notification to grant access to the member for the service(s) purchased.   Disable: Triggered when a subscription reaches its expiration date (or when an expiration is requested via chargeback or a refund/cancel request), where a username and/or password were collected at signup. The postback is a notification to remove access for the member.   Cancellation: Triggered when a member cancels his account or requests a refund and cancellation.   Reactivation: Triggered when an inactive account (previously cancelled or expired) is reactivated.
Transaction	Triggered by any transaction (payment, refund, void, chargeback, etc.). You can create up to four post backs to be triggered after transactions:   Trans Post.

Setting up Postbacks

You can set up postbacks in the SegPay Merchant Portal. Go to My Websites and select Manage Postbacks.

 

For each type of postback, enter the URL that Segpay should request when a related event occurs.

Optionally, you can create a Custom postback by requesting some (or all) of the available data be passed back to you. You can also customize the name of each parameter; for example, in the simple Custom Inquiry postback example below, we show &username=<extra username>, however instead of "username" you can enter any other descriptive name you like, such as: &user=<extra username>.

www.yourserver.com/scriptname.php?action=<action>&username=<extra username>

Or, you can accept a Default postback by including no parameters in your URL string, in which case all available data will be sent to you by default.

The following section will describe how to set up postbacks; and will provide Default and Custom URL examples for each postback type. Custom URL examples will  show a "simple" request - with just one or two parameters - along with a custom request that explicitly request all available parameters. 

You’ll see the following fields when setting up any postback:

Field	Description
URL	Domain where SegPay sends the postback. Uses SSL by default.
Expected Response	Text that is passed back to SegPay to indicate success; e.g., GOOD or OK.
Error Response	Text that is passed back to SegPay if the action requested was not successful; e.g., NOT_SUCCESSFUL.
Failed Postback Notification Options	-          Notification Email: Enter an email address to be notified when a postback fails. This field is required if you select the “Retry Postback” option.   -          Note: you must enter a value in the Error Response field (see row above) in order to receive the notification email.   -          Retry postback: Select this checkbox to retry failed postbacks. Member Management postbacks are retried every 5 minutes, for up to one hour. Transaction postbacks are retried every hour, for up to 12 hours. Note that if you select this option, you must enter a notification email (see above).
Password Protected Scripts	-          Domain: Enter the location of the script you entered in the URL section, if the domain is behind a password-protected area. -          Username/Password: Enter the username and password needed to access the protected domain above.

 

Reminder, when reviewing the custom postback examples below, note that the order and naming of the parameters appended to the URL can be customized however you like.

Inquiry Postback Example

Inquiry Postbacks are sent when SegPay collects a username and/or password during payment. The postback checks if the username already exists and, if so, defaults the username to the member’s email (please verify that your scripts support email addresses as usernames).

Description	Postback URL Example
Custom Inquiry (simple)	www.yourserver.com/scriptname.php?action=<action>&username=<extra username>
Custom Inquiry (all parameters sent)	www.yourserver.com/scriptname.php?action=<action>&username=<extra username>&password=<extra password>&purchaseid=<purchaseid>&tranid=<tranid>&name=<billname>&firstname=<billnamefirst>&lastname=<billnamelast>&email=<billemail>&phone=<billphone>&address=<billaddr>&city=<billcity>&state=<billstate>&zipcode=<billzip>&country=<billcntry>&ip=<ipaddress>&eticketid=<eticketid>&price=<price>&currencycode=<currencycode>&initialvalue=<ival>&initialperiod=<iint>&recurringvalue=<rval>&recurringperiod=<rint>&desc=<desc>&customvariable=<extra customvariable>
Default Inquiry	www.yourserver.com/scriptname.php

Enable Postback Example

Enable Postbacks are sent after an approved purchase where a username and/or password were collected. The postback is a notification to grant access to the member for the service(s) purchased.

Description	Postback URL Example
Custom Enable (Simple)	www.yourserver.com/scriptname.php?action=<action>&username=<extra username>&password=<extra password>
Custom Enable (With all Parameters Sent)	www.yourserver.com/scriptname.php?action=<action>&username=<extra username>&password=<extra password>&purchaseid=<purchaseid>&tranid=<tranid>&name=<billname>&firstname=<billnamefirst>&lastname=<billnamelast>&email=<billemail>&phone=<billphone>&address=<billaddr>&city=<billcity>&state=<billstate>&zipcode=<billzip>&country=<billcntry>&ip=<ipaddress>&eticketid=<eticketid>&price=<price>&currencycode=<currencycode>&initialvalue=<ival>&initialperiod=<iint>&recurringvalue=<rval>&recurringperiod=<rint>&desc=<desc>&customvariable=<extra customvariable>
Default Enable (no parameters specified). SegPay will send all available parameters including any user-defined that were set at the time of the transaction.	www.yourserver.com/scriptname.php

Disable Postback Example

Disable Postbacks are sent when a subscription reaches its expiration date (or when an expiration is requested via chargeback or a refund/cancel request), in cases where a username and/or password were collected at signup. The postback is a notification to remove access for the member.

The Disable postbacks support a limited data set:

• Action (default value is Disable)
• Username
• Password
• Purchase ID
• TranID (available with refund/voids or chargebacks)
• Refund Reason Code (available with refund/voids or chargebacks)
• Refund Code (available with refund/voids or chargebacks)
• Refunded By (available with refund/voids or chargebacks)
• URLID
• Any custom variables that were sent in the original transaction

See “Full List of Postback Parameters” section.

 

Description	Postback URL Example
Custom Disable (Simple)	www.yourserver.com/scriptname.php?action=<action>&username=<extra username>
Custom Disable (With all Parameters Sent)	www.yourserver.com/scriptname.php?action=<action>&username=<extra username>&password=<extra password>&purchaseid=<purchaseid>&tranid=<tranid>&ip=<ipaddress>&customvariable=
Default Disable (no parameters specified). SegPay will send all available parameters including any user-defined that were set at the time of the transaction.	www.yourserver.com/scriptname.php

Cancellation Postback Example

Cancellation Postbacks are sent when a member cancels an account or requests a refund and cancellation.

The Cancellation postbacks support a limited data set:

• Action (Default value is Cancel)
• Username
• Password
• Purchase ID
• TranID (sent with refund/voids or chargebacks)
• URLID
• Any custom variables that were sent in the original transaction
• Cancellation Reason Code
• Cancellation Code
• Cancelled By

See “Full List of Postback Parameters” section.

 

Description	Postback URL Example
Custom Cancellation (Simple)	www.yourserver.com/scriptname.php?action=<action>&username=<extra username>
Custom Cancellation (With all Parameters Sent)	www.yourserver.com/scriptname.php?action=<action>&username=<extra username>&password=<extra password>&purchaseid=<purchaseid>
Default Cancellation (no parameters specified). SegPay will send all available parameters, including any user-defined that were set at the time of the transaction.	www.yourserver.com/scriptname.php

Reactivation Postback Example

Reactivation Postbacks are sent when an inactive account (which had expired, or was cancelled) is reactivated.

The Reactivation postbacks support a limited data set:

• Action (Default value is: Reactivation)
• Username
• Password
• Purchase ID
• URLID
• Billname (Customer’s first and last name)
• Rval (Recurring amount)
• Currencycode
• Reactivation timestamp
• EticketID
• Last bill date (the last date the customer was billed for this subscription)
• Next bill date (the next date the customer is scheduled to be billed for this subscription)
• Any custom variables that were sent in the original transaction

See “Full List of Postback Parameters” section.

 

Description	Postback URL Example
Custom Reactivation (Simple)	www.yourserver.com/scriptname.php?action=<action>&username=<extra username>
Custom Reactivation (With all Parameters Sent)	www.yourserver.com/scriptname.php?action=<action>&username=<extra username>&password=<extra password>&purchaseid=<purchaseid>&name=<billname>&recurringvalue=<rval>&currencycode=<currencycode>&eticketid=<eticketid>&url=<urlid>&reactivationdate=<reactivationtimestamp> &nextbilldate=<nextbilldate>&lastbilldate=<lastbilldate>
Default Reactivation (no parameters specified). SegPay will send all available parameters, including any user-defined that were set at the time of the transaction.	www.yourserver.com/scriptname.php

Transaction Postback Example

Note: You can have up to four Transaction postbacks. They are labeled as ”Trans Post” in the Segpay Merchant Portal. Use more than one if you want Segpay to send transaction data to multiple locations; for example, some clients do this to compare their own data to third party reporting.

Description	Postback URL Example
Custom Trans (With all Parameters Sent)	www.yourserver.com/scriptname.php?action=<action>&stage=<stage>&approved=<approved>&trantype=<trantype>&purchaseid=<purchaseid>&tranid=<tranid>&price=<price>&currencycode=<currencycode>&eticketid=<eticketid>&ip=<ipaddress>&initialvalue=<ival>&initialperiod=<iint>&recurringvalue=<rval>&recurringperiod=<rint>&desc=<desc>&username=<extra username>&password=<extra password>&name=<billname>&firstname=<billnamefirst>&lastname=<billnamelast>&email=<billemail>&phone=<billphone>&address=<billaddr>&city=<billcity>&state=<billstate>&zipcode=<billzip>&country=<billcntry>&merchantpartnerid=<extra merchantpartnerid>&transGUID=<transguid>&standin=<standin>&xsellnum=<xsellnum>&billertranstime=<transtime>&REF1=<extra ref1&customvariable=<extra customvariable>&relatedtranid=<relatedtranid>&singleusepromo=<singleusepromo>&paymentaccountid=<paymentaccountid>
Default Trans (no parameters specified). SegPay will send all available parameters, including any user-defined that were set at the time of the transaction.	www.yourserver.com/scriptname.php

Transaction Postback Matrix

Use the chart below to determine the type of transaction, based on the combination of trantype, action, stage and approved parameters you receive in the postback:

 

Postback specs

- No need to enter http in the post back fields; it is pre-pended automatically (https is pre-pended if you selected “use SSL”).

- Post back communication can include upper and lower-case characters, so your validations should not be set up to require case-sensitivity.

- When entering text for response codes, use a simple data string such as TransactionConfirmed. Including html, spaces, line breaks, etc., can break the post back.

- The following postback types are synchronous – they will wait for a response from your system and timeout if nothing is received:

• Inquiry
• Enable/Disable

- The following postback types are asynchronous – these do not wait for a response; they use conventional http response codes to indicate success or failure of a request. (For details, see: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html).

• Transaction

Full List of Postback Parameters

 

The following chart defines all of the parameters you can add to postback URLs, and specifies the types of postbacks where each parameter can be used. You can add specific parameters to the postback URL in the order you want or, if you add none, all available parameters for the specific postback are passed to you. 

 

 

 

Parameter	Definition and Values	Inquiry	Access Enable	Access Disable	Cancel-lation	Re-activation	Trans-action
<Action>	The action that generated this postback. Default values are:   Inquiry Postbacks: “Probe” – A username and/or password was collected during payment. Segpay is making sure the username is available in your system. If it isn’t, we will assign the consumer's email address as the username.   Access Enable Postbacks: “Enable” – Access to your system has been granted, following a purchase.   Access Disable Postbacks: “Disable” – Access to your system has been removed, following an account cancellation/expiration.   Cancellation Postbacks: “Cancel” – A member has requested a cancellation or a refund/cancellation.   Reactivation Postbacks: “Reactivation” – A cancelled or expired subscription has been reactivated.   Transaction Postbacks: “Auth” – An authorization has occurred. “Void” – A void has occurred.	X	X	X	X	X	X
<stage>	The type of transaction that triggered the event. Supported values are: “initial” – First transaction of this type. “conversion” – First rebill of a subscription. “rebill” – Subsequent rebill transactions after a conversion. “instantconversion” – Consumer has converted prior to original conversion date.	X	X				X
<approved>	“yes” – Authorized transaction. “no” – Declined transaction.	X	X				X
<trantype>	Type of transaction. Either: “sale” – Sale. “charge” – Chargeback. “credit” – Refund.	X	X				X
<purchaseid>	PurchaseID of transaction.	X	X	X	X	X	X
<tranid>	TransactionID of transaction.	X	X				X
<price>	Transaction amount. For currency type, see <currencycode>	X	X				X
<currencycode>	The currency used for the transaction. Either: “USD” – US dollar “EUR” – Euro “GBP” – British pound	X	X			X	X
<paymentaccountid>	Secure ID string used to uniquely identify the credit card used in a transaction.						X
<ipaddress>	Consumer’s IP address.	X	X				X
<relatedtranid>	Transaction ID of the original sale. Only available for refund, void, chargeback and revoke transactions.						X
<eticketid>	PackageID:BillConfigID (Signup and Stand-In only).	X	X			X	X
<ival>	Initial transaction amount authorized for the sale.	X	X				X
<iint>	Length, in days, of the Initial billing period (trial).	X	X				X
<rval>	Recurring billing amount. 0 if no recurring amount.	X	X			X	X
<rint>	Length, in days, of the recurring billing period.	X	X				X
<desc>	Bill configuration description.	X	X				X
<extra username>	Username collected on the pay page.	X	X	X	X	X	X
<extra password>	Password collected on the pay page.	X	X	X	X	X	X
<billname>	Consumer’s first and last name.	X	X			X	X
<billnamefirst>	Consumer’s first name	X	X			X	X
<billnamelast>	Consumer’s last name	X	X			X	X
<billemail>	Consumer’s e-mail address.	X	X				X
<billphone>	Consumer’s phone number. Collected on the pay page or passed to Segpay from you. Only collected on check transactions.	X	X				X
<billaddr>	Consumer’s billing street address. Collected on the pay page or passed to Segpay from you.	X	X				X
<billcity>	Consumer’s billing city. Collected on the pay page or passed to Segpay from you.	X	X				X
<billstate>	Consumer’s billing state. Collected on the pay page or passed to Segpay from you.	X	X				X
<billzip>	Consumer’s billing zip code. Collected on the pay page or passed to Segpay from you.	X	X				X
<billcntry>	Consumer’s billing country, represented by a two-character ISO code. Collected on the pay page or passed to Segpay from you.	X	X				X
<extra merchantpartnerid>	Affiliate ID passed to Segpay from you when the transaction executed. Useful if you use your own affiliate program and want to track sales through Segpay.	X	X				X
<transguid>	The transaction Global Unique Identifier (GUID) assigned to the transaction by Segpay. Used for instant conversions. NOTE: This parameter is programmatically added to a post for all instant conversion transactions.	X	X				X
<standin>	-1 = Stand-In not supported. 0 = No stand-in occurred. 1 = Stand-in occurred.  NOTE: This parameter is programmatically added to a post for all instant conversion transactions.	X	X				X
<xsellnum>	0 = Main transaction. 1 = First cross sell. 2 = Second cross sell.	X	X				X
<transtime>	Date and Time (in GMT) the transaction occurred. Sent URL-encoded. Example:   7%2f28%2f2008+3%3a38%3a43+PM+(GMT+STANDARD+TIME) Example URL Decoded: 7/28/2008 3:38:43 PM (GMT STANDARD TIME)	X	X				X
<reactivationtimestamp>	Date and Time (in GMT) the reactivation occurred. Sent URL-encoded. Example:   7%2f28%2f2008+3%3a38%3a43+PM+(GMT+STANDARD+TIME) Example URL Decoded: 7/28/2008 3:38:43 PM (GMT STANDARD TIME)					X
<nextbilldate>	Next rebill date for re-activated subscription: mm/dd/yyyy					X
<lastbilldate>	The last date the re-activated subscription was billed: mm/dd/yyyy					X
<extra ref1> through <extra ref10>	Ref Variables are merchant reference variables. Segpay will store these variables along with the transaction, and they can be retrieved at a later time. Unlike user-defined variables, Ref values are encrypted in our database and passed back in all reports.	X	X				X
<extra xxxx>	All variables that are passed in on the pay page request via GET or POST variables will be matched to any “extra” variables and returned.	X	X				X
<ccfirst6>	First 6 digits of the card number (the BIN number).   The merchant needs to be configured to be able to receive this variable.						X
<cclast4>	Last 4 digits of the card number.   The merchant needs to be configured to be able to receive this variable.						X
<authcode>	Represents the response code for a transaction. Should use the normalized bank response table to return the appropriate decline message to the merchant.						X
<ccbincountry>	Two-character ISO code representing the country associated with the credit card BIN value.						X
<refundreasoncode>	Reason code the user chose when refunding the transaction. Only passed back for refund and void transactions.			X			X
<refundcomment>	The additional comment entered when a refund or void is processed. Only passed back for refund and void transactions.			X			X
<refundedby>	Name of the consumer that refunded the transaction. Only passed back for refund and void transactions.			X			X
<cancelreasoncode>	Reason code the consumer chose when refunding the transaction. Only passed back for refund and void transactions.				X		X
<cancelcomment>	The additional comment entered when a cancellation is processed. Only available in the cancellation postback.				X		X
<cancelledby>	Name of the consumer that cancelled the transaction. Only available in the cancellation postback.				X		X
<cardtype>	Available values are: Visa, MasterCard, JCB, Discover, eCheck and DirectDebit.						X
<extra browsertype>	Browser type identified at the time of the transaction. Can include a variety of values as there are many different browser types.	X	X				X
<extra browserversion>	Browser version identified at the time of the transaction. Example:  Mozilla%2f5.0+(Windows+NT+6.3%3b+WOW64)+AppleWebKit%2f53	X	X				X
<extra ipcountry>	Two-character ISO country code associated with the IP address for the transaction.	X	X				X
<extra ismobiledevice>	Values are: True or False, to indicate if transaction originated on a mobile device.	X	X				X
<extra platform>	The platform identified at the time of the transaction.	X	X				X
<extra template>	Paypage template associated with the package for the transaction.	X	X				X
<prepaidindicator>	Values are: Y or N, to indicate if payment was made via a prepaid card.	X	X				X
<urlid>	Numeric value representing the website ID in the Segpay system.	X	X	X		X	X
<singleusepromo>	Values are: Yes or No, to indicate whether a sale is associated with a single-use promotion. NOTE: This parameter is programmatically added to a postback for all single use promo transactions.						X
<SCArequired>	Values are: Yes or No, to indicate if transaction required Strong Customer Authentication, via 3-D Secure, in accordance with PSD2 regulations (NOT CURRENTLY BEING ENFORCED).  Notes:  -    Applies to Europe-to-Europe transactions in regions where PSD2 will be enforced.  The SCArequired parameter is added to custom postbacks even if not specified in the URL string.						X
<3DSauthenticated>	Values are: Yes or No, to indicate if customer was authenticated via 3-D Secure. NOTE: The 3DSauthenticated parameter is added to custom postbacks even if not specified in the URL string.						X
<3DSauthenticationtype>	NOT CURRENTLY USED. Will include type of 3-D Secure authentication  used.						X
<authprice>	Converted amount, in an Amount Verification transaction, according to your base currency and the exchange rate on the day of the transaction.						X
<authcurrency>	Currency used for Amount Verification transaction, based on consumer’s selection.						X

 

 

One Click Pricing

Now that you’ve set up all of your payment links for new consumers to access your site, let’s introduce a couple of payment options you can offer existing consumers. First up: One-click payments. This allows consumers who have already bought from you to make additional purchases without re-entering card information (the one-click option is only available for credit card payments).

One-click base URL:

https://secure2.segpay.com/billing/OneClick.aspx?x-eticketid=122903:9689

Any price point passed for one-click payment must have been originally set up with One Click enabled (In the example above, the ID of the price point is 9689). To enable a price point for one-click payment, ask your SegPay rep; or go to the Merchant Portal and select My Websites, then Price Points. Edit any price point and look for the following checkbox:

 

You can append any of the parameters discussed in previous sections to the base URL, however, the following is required to request a One-click payment page:

&OCToken

The purchase ID, which should be stored in your database following the original sale. Allows SegPay to charge the card used for that sale.   Example:   https://secure2.segpay.com/billing/OneClick.aspx?x-eticketid=122903:9689&OCToken=XXXX   Note that a Purchase ID associated with a subscription that has been expired for 30 days or longer is not valid as an OCToken and, if used, will direct to a full payment page.     Purchase IDs associated with Digital Purchase and Dynamic price points do not expire and can be used indefinitely as OCToken values.

 

* Remember that the x-eticketid values in the URL above are only examples, and will be different in the version you are sending.

One-click payment example:

 

 

Notes:

• Consumers are only required to enter the CVV value from their card (see image above).
• For a one-time purchase (including digital downloads), the new payment is associated with the original purchaseID. The one-click payment is classified as a rebill – in both reports and postbacks – so it can be associated with the original purchase.
• For a recurring purchase (a subscription), a new purchaseID is generated. The one-click payment is classified as an Initial purchase – in both reports and postbacks – in order to better track the lifecycle of the membership, for example tracking a trial to full membership.
• If Inquiry and Enable/Disable postbacks are set up, they will work as long as a username and password are sent with the transaction.
• One-clicks cannot be used with Delayed Capture price points.

 

Single Use Promotions

Single Use Promotions (Promos) allow you to create a special promotional offer that is only available for a limited time. Because it is a limited time promotion, you have the flexibility to make an aggressive pricing offer to entice new customers without worrying about repeat purchases. You can limit a Single Use Promo to one redemption per credit card (or other payment account), email address and/or username – or any combination of the three. You can also choose to make the offer redeemable again in, say, a month or whatever time period you specify; and you can limit the offer to one use per website (if you have multiple sites).

 

When creating a price point in the Segpay Merchant Portal, select the Single Use Promo option.

 

 

You then decide how exactly you want to limit use of your promo:

 

1. Limit one use per (SELECT ONE OR MORE): Select credit card, email, username, or any combination of the three to restrict re-use of your promo. For example, if you select email, consumers can redeem the promo once with a specific email, but can only redeem it again using a different email address.

2. Consumers can re-use this promo after ___ days. You can allow re-use of your promo after a specific number of days have passed. Enter that number here or leave blank to restrict the promo to just a single use, ever.

 

 

3. Consumers can use this promo once per website (if you have multiple sites). Select this option if you have multiple sites and want to allow consumers to buy your promo once per site. For example, a consumer may redeem the promo on Site A, then again on Site B. The same consumer would not be able to re-use the promo on Sites A or B (subject to your setting in step 2), however they can still re-use it on any additional sites you have. Leave this option un-checked to restrict the promo to a single use across all of your websites.

 

 

When a consumer redeems a Single Use Promo, it will trigger a Transaction post back with the parameter, singleusepromo=yes.

 

Instant Conversion

Next up: Instant Conversion. This type of price point allows a consumer to convert to a full membership immediately, before a limited trial period ends. The offer will be valid up to 12 hours before the end of the trial.

When setting up an Instant Conversion price point, you can decide to reward your consumer in two ways:

1. Discount price: Give your consumers an incentive to convert early by offering a discount rate if they do. Specify the discounted price – which applies to the initial and recurring payments – that they will be charged if they choose instant conversion:

2. Adjust Trial Length at Time of Conversion: Select this option to set the consumer’s re-bill date for 30 days (or the length of your billing interval, if different) from the day he/she chose instant conversion. Leave it unchecked and the re-bill date will remain at 30 days from when the trial was originally supposed to end.

Example:

• Consumer signs up Sept 1^st.
• Free trial is set to end on Sept. 10^th and convert to a full membership with re-billing on the 10^th of every month.
• Instead, consumer chooses Instant Conversion on Sept. 5^th and is converted to full membership on that date.
• With Adjust Trial Length selected, next bill date is set for Oct. 5^th.
• Otherwise, next bill date remains Oct. 10^th.

 

Note: Find these options in the Merchant Portal under My Websites, then Price Points. “Stand-In” processing is explained in the next section.

When a consumer signs up for a price point set up for instant conversion, the parameter stage=INSTANTCONVERSION is passed to you in the post back. This triggers the instant conversion option to be presented to that consumer during his/her trial. The button linking to the Instant Conversion offer will trigger a request that is structured like the following URL:

https://secure2.segpay.com/billing/InstantConv.aspx?ICToken=XXXX

Note that the price point being passed must have been originally set up as an Instant Conversion price point (In the example above, the ID of the price point is 9689). You must append the ICToken parameter when requesting an Instant Conversion payment page. Here’s a definition of ICToken and one additional parameter you can pass:

Parameter	Definition
ICToken   (required)	The transguid value that was passed to you – via the transaction post back – after the original purchase.   Example:   https://secure2.segpay.com/billing/InstantConv.aspx?ICToken=XXXX
IC301Text   (optional)	Customize the error message that displays if the SegPay system is not ready to process the payment. This can happen if the consumer chooses instant conversion very quickly after his original signup (within two minutes).   The default error message asks the consumer to try again in two minutes. Uses this parameter only if you want to customize the message. For example:   https://secure2.segpay.com/billing/InstantConv.aspx?ICToken=XXXX&IC301Text=Please+retry+your+upgrade+in+a+few+minutes!

 

* Remember that the x-eticketid values in the URLs above are only examples, and will be different in the version you are sending.

By default, the consumer is asked to provide an email address for instant conversion, as in the example below. Ask your SegPay rep if you don’t want to require an email.

 

A successful Instant Conversion transaction will trigger a Transaction post back (see Post back Notifications section above) but Inquiry and Access post backs will not be sent.

Stand-in

Stand-In Processing – Stand-in refers to the optional process that can be triggered when SegPay is unable to communicate with a bank. Instead of issuing a decline, SegPay temporarily approves the transaction and then retries it up to three times every two hours. This continues until the bank authorizes or declines the transaction or the maximum number of retries is exceeded.

Stand-in is most useful for small dollar trial subscriptions where the merchant cost for providing temporary access is low. If you want SegPay to run stand-in processing, select the “Enable Stand-In” option when setting up a payment package in our Merchant Portal:

Note that stand-in is not available for Delayed Capture price points.

When a Stand-in is initially approved, it triggers three post back notifications: Inquiry, Enable and Trans Post. The Trans Post will include the parameters transid and purchaseid.

If a stand-in transaction is ultimately declined, two post back notifications are sent: a new Trans Post – which will include the same transid and purchaseid values from the original temporary approval so you can easily tie the two transactions together (see Transaction section under “Setting Up Postbacks” above for details on what is included in the postback) – and, if a username was associated with the signup, a Disable is also sent to disable the consumer’s access.

The following SegPay SRS reports will include the final decline:

• Assets Active Subscriptions by URL
• Transactions List Declined
• Transactions Purchases by URL

 

See the “SRS Web Service Reports” section below for more information about these reports.

SRS Web Service Reports

SegPay recommends that reporting services are used in conjunction with the postback notification system. There are several benefits:

1. Pulling data from reporting services provides a backup in case postbacks don’t go through.
2. You can pull data from reporting services on a set schedule, for use as a reconciliation tool. We recommend you pull transaction data from the previous day’s transactions only. As a reminder, the Segpay system operates on GMT.

 

For information regarding Segpay’s Reporting Services, please visit: https://www.sphelpdesk.com/kb/article/37-segpay-reporting-services-srs/ or: https://srs.segpay.com.

Data Availability Chart

Data Element	Definition	SRS	Postbacks
URL	Website	X	X
Transaction ID	n/a	X	X
Related Transaction ID	Original transaction id associated with a chargeback, refund or void	X	X
Transaction Time	time stamp of transaction	X	X
Type	Sale, void, refund, chargeback, one click	X	X
Source	Sign-up, conversion, rebill, system	x	X
Auth	Yes or no	X	X
Transaction Amount	n/a	x	X
Currency	n/a	X	X
AuthCode	Bank response to an authorization or decline	X
Purchase ID	n/a	X	X
Purch Type	Identifies if one time, recurring, digital purchase, instant conversion or delayed capture	X
Customer Name	n/a	X	X
Customer Email	n/a	X	X
Customer Address	n/a	X	X
Customer City	n/a	X	X
Customer State	n/a	X	X
Customer Zip	n/a	X	X
Customer Country	n/a	X	X
Customer Phone	n/a	X	X
Customer IP	n/a	X	X
IP Country	n/a	X
Username	n/a	X	X
Data Element	Definition	SRS	Postbacks
Password	n/a	X	X
Purchase Status	Status of the subscription (active, cancelled, expired)	X
Initial Amount	Sign-up amount	X	X
Recurring Amount	n/a	X	X
Recurring Period	n/a	X	X
Next Date	Next rebill date	X
Cancel Date	Date consumer cancelled	X
Expired Date	Date membership expires	X
Retries	Number of times a rebill has been re-tried when the first attempt failed. Value=1, 2 or 3	X
Retry Date	n/a	X
Last Result	Identifies the approval or decline result of most recent transaction	X
Merchant Partner ID	The affiliate ID passed in by the merchant.	X	X
eticketID	This is the package ID and bill config ID to identify the price point and website the purchase was made to	X	X
REF Variables	Up to 10 variables that you pass through (REF1 - REF10)	X	X
UserData	Grouping of all user-defined variables passed through by the merchant. In the SRS reports it also includes paypage languages and browser type/version	X	X
Bin / First 6	First 6 credit card digits	X	X
last 4	Last 4 credit card digits	X	X
Bin Country	Country where Bin is from	X
Refund Entered By	n/a	X
Refund Reason Code	n/a	X
Refund Comment	n/a	X

Testing Payments

Credit Card Transactions

You can test credit card transactions in both TEST mode and LIVE mode. When in TEST mode, you can complete a full signup, including one-click and instant conversions. This generates transactions in test mode (nothing is sent to the bank) and triggers confirmation emails and postbacks. Transaction Postbacks generated in TEST mode will automatically append the parameter, TESTTRANS=1.

Currently, rebills, refunds and voids cannot be processed in test mode.

When you are in TEST mode, the following notification displays at the bottom of the payment page:

 

When you see this notification, you can use the test credit card numbers to generate an approval or decline:

For an Approval, use test card: 4444 3333 2222 1111

For a Decline, use test card: 4444 4444 4444 4455

When testing in LIVE mode, the Approval card above can be used to generate a decline. To generate an approval in LIVE mode, please contact [email protected] and we will send you a LIVE test card number (which will not send transactions to the bank). As in test mode, this will work for signups, one-clicks and instant conversions, while generating emails and postbacks; but, again, will not allow testing of rebills, refunds or voids.

In LIVE mode, all unsuccessful payment attempts are evaluated against Segpay's fraud detection system, and a score is assigned, based on how likely it is that the transaction was fraudulent. When fraud is less likely, a lower score is assigned, and the consumer may be permitted to re-try the payment one or more times. In TEST mode, this fraud scoring system is disabled by default, so all unsuccessful attempts result in hard declines with no ability to re-try the payment. You can enable the scoring/retry system in TEST mode by appending the following parameter to your Join link:

?TestModeRetryDecline=on

 

Direct Debit Transactions

Testing varies depending on the country. Please see below for test information specific to each country.

Along with the information below, you can enter your own phone number to simulate the customer experience, in which you will receive a phone call with the TEST PIN number to complete the transaction (the PIN will be spoken in the language of the country you are testing). Or, use the following phone, regardless of the country, to receive the PIN via email:  +49 (Germany) 000 00000.

Enter the pin on the PIN Page and continue to the approval page. Note that these details only work in TEST mode.

 

Germany:

Name Jürgen Müller

Street: Hedwigstr. 3

Zip: 45892

City: Gelsenkirchen

Account no.: 596015202

Bank Routing No: 20010020

Account Owner: Jürgen Müller

 

Netherlands:

Name: Michel Uppendan

Street: pietheinstraat 26

Zip: 1215la

City: Hilversum

Account no.: 637037316

BankName: Commerzbank AG

BankCity: Hilversum

Account Owner: Michel Uppendan

 

Spain:

Name: José Hernandez

Street: Ermita de la Salut, 58

Zip: 43007

City: Tarragona

Account no.: 0159000134365653597

Account Owner: José Hernandez

 

Austria:

Name: August Hübner

Street: wienerstr. 3

Zip: 7540

City: Guessing

Account no.: 51574003707

Bank Routing No: 12000

Account Owner: August Hübner

 

United Kingdom:

Name: Mike Hammer

Street: 95 Wilton Road

Zip: SW1V 1BZ

City: London

Account no.: 30145600

Bank Sort Code: 406201

Account Owner: Mike Hammer

 

Italy

IBAN:  IT89W060451168800078202014                                
BIC: CRBZIT2B160   

 

All Other Countries

IBAN: 1257855654771548

BIC: 75487156325

 

Failed Transaction Error Codes

When a transaction fails due to suspected fraud, your postback notification will include one of the error codes listed in the table below. Next to each error code is a description of the specific fraud type that caused the transaction to fail.

Response Code	Short Description	Long Description
F440	SPVelocity	Instant Conversion Validation Errors exceeded.
F451	SPNegDB	Card negative database
F452	SPNegDB	E-mail negative database
F453	SPNegDB	E-mail negative database
F455	SPNegDB	CustCountry or IP Country
F456	SPNegDB	Merchant CustCountry or IP Country block.
F457	Dupe	Duplicate Subscription
F458	SPNegDB	Merchant URL CustCountry or IP Country block.
F460	SPVelocity	Global Velocity
F461	SPVelocity	Merchant Velocity (Card Number)
F462	SPVelocity	Merchant Velocity (E-Mail)
F463	SPVelocity	URL Velocity (Card Number)
F464	SPVelocity	URL Velocity (E-Mail)
F465	SPVelocity	Merchant Velocity (IP Address)
F470	SPNegDB	BIN Block – Negative Database
F471	SPNegDB	BIN Block – BIN Country
F481	SPNegDB	MerchantPartnerID Block
F492	MerchNegDB	E-mail negative database
F493	SPNegDB	Merchant CustCountry or IP Country block.
F494	SPNegDB	Device negative database
V3001	SPVelocity	URL Velocity (Card Number)
V3002	SPVelocity	URL Velocity (E-Mail)
V3003	SPVelocity	URL Velocity (Username)
V3004	SPVelocity	URL Velocity (IPAddress)
V3005	SPVelocity	Merchant Velocity (Card Number)
V3006	SPVelocity	Merchant Velocity (E-Mail)
V3007	SPVelocity	Merchant Velocity (Username)
V3008	SPVelocity	Merchant Velocity (IPAddress)
V3009	SPVelocity	URL Velocity (DeviceID)
V3010	SPVelocity	Merchant Velocity (DeviceID)
V3011	SPVelocity	URL Velocity (TrueIP)
V3012	SPVelocity	Merchant Velocity (TrueIP)

 

Instant Conversion/One-Click Errors

Error code	Description
ERR301	Token doesn't exist in the Segpay System
ERR302	Bill Config assigned to asset record is not an Instant Conversion
ERR303	Signup Transaction was not authorized
ERR304	Purchase record has already been converted
ERR305	Purchase record has a null value for NextDate
ERR306	Purchase record has a NextDate within the cutoff for a conversion
ERR307	Invalid PackageID/BillConfigID on the conversion
ERR308	Unsupported card type on Asset
ERR309	Card type no longer supported by processor pool
ERR310	Purchase record no longer has a status of Active