PX Pay is designed to allow merchants to send transactions to Payment Express® via https posts, which links to a 128-Bit SSL secure payments page at https://www.paymentexpress.com/pxpay/pxaccess.aspx. The cardholder is
automatically prompted to enter their details and a response is displayed. The result is automatically communicated back to the original site the transaction came from.
The product is platform independent as the host interface handles XML, which can be generated with any language on the client side.
A redundant post of the response is given back to the merchant site. No session variables will be included in this response as it is independent of the merchants web server.
| Technical Specifications/Features: |
|
| Requirements/ Downloads: | ||
|
How it works -
Transaction RequestThe following is a description of the inputs and outputs of the transaction request. GenerateRequest (Input XML Document) |
| Input Element | Required | Description |
Yes |
Your account's UserId |
|
Yes |
Your account's 64 character key |
|
Yes |
Amount value in d.cc format. |
|
| BillingId | No | Needs to be generated to add a card for recurring billing and sent again when rebilling transactions. |
Yes |
Currency of AmountInput |
|
| DpsBillingId | No | The BillingId generated by DPS when adding a card for recurring billing. Needed for rebilling transactions when you do not use your own BillingId. |
| No | DPS transaction reference. Sent back to DPS for refund and complete transactions. |
|
No |
Optional Email Address |
|
| EnableAddBillCard | No | Needed for recurring billing transactions when adding a card to the DPS system. Set element to 1 for true and 0 for false |
Yes |
Reference field to appear on transaction reports |
|
No |
Optional Free Text |
|
No |
Optional Free Text |
|
No |
Optional Free Text |
|
Yes |
Auth, Complete, Purchase, Refund (DPS recomend completeing refunds through other API's) |
|
| TxnId | No | Contains a unique, COM or merchant application generated value that uniquely identifies the transaction |
Yes |
Url of customer site transaction failure page |
|
Yes |
Url of customer site transaction success page |
|
| Output Element | Description |
| Whether the request was valid. "1" for valid and "0" for an invalid request | |
URL including Encrypted Transaction Request that you will need to redirect the customer to. |
|
The following is used to decode the result of the transaction after it has been submitted and get the XML response back.
| Input Element | Required | Description |
Yes |
Your account's UserId |
|
Yes |
Your account's 64 character key |
|
Yes |
The encrypted URL response from DPS, which you can get from "Result" parameter in the URL string that is returned to your response page. |
|
| Output Element | Description |
| Valid [Attribute] | Whether the request was valid. "1" for valid and "0" for an invalid request. |
The Amount of the transaction |
|
| AuthCode | Authorisation code from the bank |
| CardName | Card used (Visa,MasterCard,Bankcard etc) |
| CardNumber | The card number used for the transaction in truncated form. |
| DateExpiry | The expiry date of the card used in the transaction. |
DPS transaction reference. Sent back to DPS for refund and complete transactions. |
|
Non-zero if transaction successful, 0 if declined or unsuccessful |
|
Response Text associated with the result of the transaction |
|
Contains the billing ID generated by DPS when adding a card for recurring billing. |
|
The Card Holder Name used for the transaction |
|
The Currency of the transaction |
|
Optional Free Text |
|
Optional Free Text |
|
Optional Free Text |
|
Character data sent via PX Pay must be well formed XML. For example, the following is invalid XML:
|
Payment Express will be unable to read this XML and will return an error. If there is a possibility that a value will contain invalid characters (such as '&' in the cardholder name), please format the value using "HtmlEncoding".
The above example should be formatted as follows:
|
| CAD | Canadian Dollar |
| CHF | Swiss Franc |
| EUR | Euro |
| FRF | French Franc |
| GBP | United Kingdom Pound |
| HKD | Hong Kong Dollar |
| JPY | Japanese Yen |
| NZD | New Zealand Dollar |
| SGD | Singapore Dollar |
| USD | United States Dollar |
| ZAR | Rand |
| AUD | Australian Dollar |
| WST | Samoan Tala |
| VUV | Vanuatu Vatu |
| TOP | Tongan Pa'anga |
| SBD | Solomon Islands Dollar |
| PNG | Papua New Guinea Kina |
| MYR | Malaysian Ringgit |
| KWD | Kuwaiti Dinar |
| FJD | Fiji Dollar |
Value |
Meaning |
| Auth | Authorises a transaction. Must be completed within 7 days using the "Complete" TxnType. |
| Complete | Completes (settles) a pre-approved Auth Transaction. The DpsTxnRef value returned by the original approved Auth transaction must be supplied. |
Purchase |
Purchase - Funds are transferred immediately. |
It is highly recommended that Fail Proof result notification is configured by Payment Express. This setting (EnablePost Response) set at Payment Express host, ensures that the following process occurs for every transaction:
Transaction is performed via hosted payment page. As soon as the transaction is complete, but prior to the results being displayed for the user, a background process issues a HTTP GET to the merchant specified payment page response (UrlSuccess or UrlFail). If the merchant web site is unreachable or returns a response other than "200 OK", the GET is retried every minute for 30 minutes, thereafter every 15 minutes until a preset limit is exhausted. Merchant sites should therefore allow for the possibility that their application could receive more than one notification for the same transaction. The merchant application can distinguish which transaction the response is for by checking the TxnId value.
The Merchant application can optionally indicate a transient application failure by inserting the string <!-- Dps_ReCo=xx -->. If "xx" is any value other than "00", Payment Express will keep retrying the HTTP Request until either retries are exhausted or until the page contains <!-- Dps_ReCo=00 -->. This could be used to handle a temporary database issue at the customer site preventing successful transaction update for example.
Payment Express supports Auth/Completion. An "Auth" transaction verifies that funds are available for the requested card and amount and reserves the specified amount. A "Completion" transaction is sent at a later date to cause funds transfer for the previously authorised amount, or a smaller amount if the total original value is no longer required. This transaction set is useful when the merchant needs to ensure that funds up to a certain limit are available but the actual total amount is not yet known or goods or services have not yet been delivered.
Set TxnType to "Auth" for the amount to be authorised. The Auth response contains a DpsTxnRef. The funds are not transferred from the cardholder account.
After a successful Authorisation transaction, but within 7 days maximum, a "completion" (TxnType="Complete") transaction must be sent containing the DpsTxnRef returned by the "Auth" transaction.
Token Billing allows for regular billing of a cardholder card, under the control of the merchant, without requiring the merchant to either store sensitive card data securely or to obtain credit card details every time a new payment is requested. This functionality is implemented by proving the ability for a merchant to request payment express to capture and store a credit card number and expiry date and to link these stored details to a merchant supplied "BillingId". The BillingId is a 32 character field that contains a reference that is unique to the merchant's customer, that will be associated with the credit card information stored securely at Payment Express. This is undertaken during the Setup Phase. For subsequent charges to the card (Rebill Phase), the merchant does not need to supply the card number or expiry date, only the BillingId originally associated during the Setup Phase
The setup phase consists of loading a card into Payment Express with a transaction. The transaction can be an online $1.00 Auth transaction which will determine that the card is valid and not on hot or stolen card lists and that it has the correct expiry date.
Customers will typically integrate directly into their call centre or web application for the setup phase.
To add a card for future rebilling, send a transaction request (Auth or Purchase) including the following properties:
EnableAddBillCard (Set to 1 when adding a card)
BillingId (optional)
You can supply your own billing ID in BillingId or leave it blank and use the ID returned in DpsBillingId determined by Payment Express)
The merchant application or Batch processor requests a new transaction and supplies the appropriate BillingId or DpsBillingId, a MerchantReference, and the amount to be charged. Payment Express retrieves the credit card number and expiry date stored in the Setup Phase and a purchase transaction is formatted and processed to the card acquirer.