PX Pay Interface for the Hosted Payments Package
PX Pay allows merchants to send transactions to Payment Express® via HTTPS posts to https://sec.paymentexpress.com/pxpay/pxaccess.aspx. Payment Express® responds with a unique URL for an SSL secure payments page at which the user will be prompted to enter their credit card details and complete the transaction. The result is displayed and the user is automatically directed back to the merchant's website. The result and other transaction details can then be extracted by the merchant. PX Pay is platform independent as transaction requests and responses are made using XML which can be generated and read in any programming language.
| Technical Specifications/Features: |
|
| Requirements/ Downloads: |
Using PX Pay
- How It Works
- GenerateRequest XML Document (Transaction Request)
- Request XML Document (Transaction Request)
- ProcessResponse XML Document (Transaction Response)
- Response XML Document (Transaction Response)
- Well Formed XML
- Element Properties Description
- Fail Proof Result Notification
- Auth-Completion
- Token Billing
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 user ID |
|
Yes |
Your account's 64 character key |
|
Yes |
Amount value in d.cc format |
|
| BillingId | No | Optional identifier when adding a card for recurring billing |
Yes |
Currency of AmountInput |
|
No |
Optional email address |
|
| EnableAddBillCard | No | Required when adding a card to the DPS system for recurring billing. Set element to "1" for true |
Yes |
Reference field to appear on transaction reports |
|
No |
Optional free text |
|
No |
Optional free text |
|
No |
Optional free text |
|
Yes |
"Auth" or "Purchase" |
|
| TxnId | No | A value that uniquely identifies the transaction |
Yes |
URL of the merchant transaction failure page. No parameters ("&" or "?") are permitted. |
|
Yes |
URL of the merchant transaction success page. No parameters ("&" or "?") are permitted. |
|
No |
Optional additional parameter |
|
Request (Output XML Document)
| 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 user to. |
|
Transaction Response
The following is used to decode the result of the transaction after it has been submitted and get the XML response back.
ProcessResponse (Input XML Document)
| Input Element | Required | Description |
Yes |
Your account's User ID |
|
Yes |
Your account's 64 character key |
|
Yes |
The encrypted URL response from DPS, which you can obtain from "result" parameter in the URL string that is returned to your response page. |
|
Response (Output XML Document)
| 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 acquirer |
| CardName | Card used (Visa, MasterCard, Amex, Diners 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. Can be stored and later used to process complete or refund 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 |
|
"Auth" or "Purchase" as submitted in the GenerateRequest |
|
Currency as submitted in the GenerateRequest |
|
MerchantReference as submitted in the GenerateRequest |
|
The IP address of the user who processed the transaction |
|
The TxnId supplied in the GenerateRequest |
|
The EmailAddress supplied in the GenerateRequest |
|
The BillingId as supplied in the GenerateRequest |
|
Indication of the uniqueness of a card number |
|
Contains a token generated by DPS when adding a card for recurring billing. |
|
Well Formed XML
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:
|
Element Properties
| CAD | Canadian Dollar |
| CHF | Swiss Franc |
| DKK | Danish Krone |
| EUR | Euro |
| FRF | French Franc |
| GBP | United Kingdom Pound |
| HKD | Hong Kong Dollar |
| JPY | Japanese Yen |
| NZD | New Zealand Dollar |
| SGD | Singapore Dollar |
| THB | Thai Bhat |
| 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 |
Fail-proof Result Notification
Fail-proof result notification (FPRN) is a service that provides additional assurance that the merchant website will receive notification regarding the outcome of transactions completed via the DPS-hosted payment page.
FPRN helps cater for the possibility that a user may not successfully navigate to the nominated success or failure URL enabling the merchant web application to acknowledge the outcome of the transaction. The user could close their browser or otherwise navigate away from the DPS-hosted payment page once they have been informed of the transaction outcome. The merchant's web server may be temporarily unavailable as the transaction is completed and therefore unable to recognise that a transaction has taken place. Using the FPRN service the merchant website is virtually guaranteed to receive notification of the each and every transaction.
FPRN is highly recommended by DPS and is enabled on all new accounts by default. The service ensures that the following processes occur for every transaction performed via hosted payment page:
As soon as the transaction is completed, a background process at DPS makes an HTTP GET request to the merchant-nominated success or failure URL. If the merchant web site is unreachable or returns any HTTP status code other than 200 or 404 the HTTP GET is retried up to a maximum of six times. It will give up immediately on receiving a 404 HTTP status code (page not found). A 500 HTTP status code, indicating a temporary problem at the client site, will cause a retry.
In order to ensure that the web application is in the best position to acknowledge the outcome of each and every transaction certain guidelines should be followed.
The merchant web application should not;
- Filter or base any conditional logic upon the originating IP address (this can vary)
- Depend upon receiving one and only one request for the success/fail URL from the DPS FPRN system (multiple requests may be sent)
The merchant web application should;
- Decrypt the query string for all requests for a success/fail page requests where the requested URL contains a 'result' parameter containing the encrypted transaction outcome details
- Determine if a database operation or some form of communication such as generating an order record or sending an email is required. Generally this will mean that the application needs to be aware if these actions have been taken previously for the particular transaction or not (TxnId should be used for this purpose).
N.B. The URL at which the merchant website will process FPRN requests must be exposed via standard internet ports i.e. port 80 or port 443 for SSL/TLS traffic. When specifying UrlSuccess and UrlFail values do not specify a non-standard port number within the URL.
Auth-Completion
Overview
Payment Express supports Auth/Completion. An authorisation ("Auth") transaction verifies that funds are available for the requested card and amount and reserves the specified amount. A Completion ("Complete") 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.
Operation
1) Authorisation
Set TxnType to "Auth" for the amount to be authorised. The ProcessResponse output contains a DpsTxnRef to be stored. The funds are not transferred from the cardholder account.
2) Completion
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. See here to process a completion programatically or here to process a completion manually.
Token Billing
Overview
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 transaction is made. 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
1) 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®
2) Rebill Phase
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 processes a transaction to the associated card.

