Skip to main content

PayWay Classic API Developers Guide

The PayWay solution allows customers to process credit cards using an Application Programming Interface (API). All communications between the customer's system and API takes place securely.

The API offers the customer a range of credit card processing features including:

  • Capture - debit funds from a nominated credit card
  • Refund - credit funds to a nominated credit card
  • Pre-authorisations - reserve funds from a nominated credit card and capture later
  • Account Verification - check if a credit card is valid
  • Query - query the result of a previously attempted transaction
  • Echo - check the status of the API service

The API supports multiple connectivity options (Internet, Leased Line) and technologies (Java, COM, ASP, .NET, PHP and SOAP) so there is a solution to suit most customers. All major credit and charge card types such as Visa, Mastercard, UnionPay, Amex, JCB and Diners may be processed through PayWay. EFTPOS debit card transactions can not be processed.

The actual concept of the API is simple. The Customer System will send a Credit Card API Request to PayWay, containing either:

  • A unique order number, credit card details and amount, OR
  • A unique order number, recurring billing customer number and amount

PayWay will send back an API Response, containing details on whether the transaction was successful or not.

Is it secure?

For a solution of this nature, security is critical. Westpac/St. George must be absolutely confident that they are receiving a credit card processing request from an authorised source. To ensure the source of the request is valid:

  • The Merchant must be registered before credit card processing will begin. Part of this registration will be to issue the customer with a username and password. This username/password combination must be passed in with every request.
  • PayWay will only accept requests from pre-configured IP addresses.
  • For high volume customers Qvalent will recommend that a leased line (i.e. Frame Relay) be installed between the customer's site and Qvalent's data centre. If you intend to perform more than 100,000 transactions per month through the Credit Card API, please discuss this option with your Westpac implementation manager.
  • For added security a card verification number (CVN) can be supplied with the credit card API call.
  • All transaction data will be communicated via HTTPS with 128-bit encryption and each message digitally signed (MAC). A digital certificate is provided to each customer for this purpose.
  • Using the API in conjunction with the PayWay Recurring Billing and Customer Vault module means that the merchant does not need to store or handle credit card details in their system.

The connectivity options are as follows:

  • Leased line. Dedicated link between the customer's site and Westpac's credit card server. In this scenario, no data would be transmitted over the Internet. Username / password and digital certificate are required.
  • Internet. Credit card transactions are passed over the Internet. Username / password and digital certificate are required.

In both cases above, Qvalent will provide you with a digital certificate (via download), username and password. This certificate will be in the form of a file that you will deposit into a directory on your server. Qvalent also will ask you to set up the IP addresses which are allowed to send transactions for your company.

All attempts to use the credit card service are logged. This includes Internet connections, API calls and the success or failure of those calls. Logs will be written to permanent storage. Logging will include the IP address of the caller and all the information sent and received to that destination.

Credit card details are protected as follows:

  • Credit card numbers and expiry dates are stored in encrypted form in the database. Credit card numbers are recorded in truncated form in system logs (ie first few and last few digits only)
  • Card verification number (CVN) is not stored in the database or in system logs. The value is passed on as is to the banking network and only a record of whether a value was provided or not is retained.

Finally, refunds are restricted to only be allowed against previous captures so there is no risk of fraudulent activity within your business.

Getting started

Implementing the Credit Card API

Setup

Follow these steps:

  1. Sign-in to the PayWay website using the login name and password provided to you by your implementation manager.
  2. Download the API software for your technology from the PayWay website. The supported technologies are Java, Microsoft .NET, Microsoft COM/ASP, PHP and SOAP. Click on the gear icon for Settings in the menu and then choose PayWay Classic API -> Downloads.
  3. Extract the software bundle (which is a ZIP file) to a folder, and review the PayWay API for... PDF document in that folder. Follow the instructions in that document to install the API software.
  4. If necessary, configure your firewall to allow outbound SSL traffic (port 443) and determine if you need to use a proxy server to communicate with the PayWay server.
  5. Get your API username and password from the PayWay website and record these details for use in your application. This is information listed on the Security page under the Setup API heading. Note that this username and password is for your application to connect with the PayWay API server and is different from the username and password that you used to access the PayWay website.
  6. Download your certificate from the PayWay website on the Certificate page under the Setup API heading. You must first select the technology you are using and press the Go button, since different certificate formats are required depending on your application technology. Record the location of the certificate file for use in the initialisation of the PayWayAPI object.
  7. Develop your API solution by integrating the API into your application.
  8. To determine your IP address, perform a test transaction with the correct username, password and certificate. You will receive a QU response code, and the response description will tell you your IP address. Add this IP address to the security access list on the Security page under the Setup API heading.

Any questions or issues regarding development should be emailed to PayWay Customer Care. Please include your name, client number, description of the issue and a copy of the log file in the email. The log file can be found in the logDirectory you selected. A member of our support team will assist you as soon as possible.

Never send credit card numbers in an email.

Testing

For any customer wishing to implement our credit card API, we provide a test merchant which simulates responses rather than sending the transaction to the live banking network. This test merchant is accessed through the normal production URL, but the customer merchant specified is TEST.

The test merchant simulates a live gateway but may be used without any risk of transactions actually being processed through the banking system. When using the test merchant, only test card numbers are valid. See Test card numbers.

Refer to the technology specific API documentation provided on how to carry out a test transaction.

Viewing test transactions

You can view test transactions in PayWay as follows:-

  1. Sign-in to PayWay
  2. Click Search and Refund under the Transactions menu item
  3. Select the Settlement Date of the transaction and Test - Test Merchant
  4. Click Search

Recurring Billing and Customer Vault

If you wish to use the credit card API in conjunction with the recurring billing and customer vault module, you will need to set up a test customer as follows:

  1. Sign-in to PayWay
  2. Click Add Customer under the Customers menu item
  3. Choose a customer number (e.g. TESTCUSTOMER1) and enter a name
  4. Select Variable Debit
  5. Click Next
  6. Choose Credit Card
  7. Click Next
  8. Enter one of the test card numbers listed above.
  9. Click Next
  10. Confirm the details and click Save

You can now call the Credit Card API and pass in the customer number you selected instead of card details (see Using Recurring Billing and Customer Vault to hold Credit Card Details, page 28).

In your API request specify:

customer.merchant=TEST&customer.customerReferenceNumber=TESTCUSTOMER1

If you wish to disable the test customer, you can do this as follows:-

  1. Sign in to PayWay
  2. Click Search and Edit under the Customers menu item
  3. Enter the customer number of the test customer (e.g. TESTCUSTOMER1)
  4. Click Search
  5. Click Edit Customer
  6. Choose Recurring Billing Setup and click Go
  7. Click Stop Remaining Payments
  8. Confirm that you wish to Stop Remaining Payments

The customer is now stopped and can not be charged through the API.

Production

Going live

Once you have developed and tested your API solution, you are ready to go live. Before this can happen, your implementation manager must set up billing and provide you with a live merchant id.

When these two steps are completed, you must press the Go Live button on the Go Live page under the Setup API heading of the PayWay website.

Once you press this button, you may perform live transactions against your live merchant id. However, you may still use your TEST merchant id to perform test transactions. Transactions to your TEST merchant will not appear on the cardholder statement, or your bank account. We recommend that you process one live transaction before you start sending all your transactions to the new system. The day after you perform this test transaction, you should check your settlement account to make sure that the funds from this transaction arrived in your account. Once this verification is done, you can then switch all your live transactions to the new system.

Support

For issues relating to Credit Card API development, Contact Us. Please include your name, client number, description of the issue and a copy of the log file in the email. The log file can be found in the logDirectory you selected.

API

The PayWay API provides a real-time interface to execute credit card transactions. This interface uses the familiar concept of a remote procedure call (RPC). The customer invokes the remote method with the credit card details then the PayWay server processes the transaction and returns the result in real-time.

A transaction contains the following steps:

  1. Customer calls the API initialise method. This loads the URL, loads the certificate and initialises SSL.
  2. The Customer uses the processCreditCard client command to submit a credit card transaction. The API digitally 'signs' the request to allow the PayWay server to verify the request originator and sends the request to the PayWay server.
  3. The Customer waits for a response to be returned through the API connection.
  4. The PayWay server verifies the digital 'signature', merchant username / password and IP address of the originating request. If all these are valid, the server verifies the other credit card request parameters.
  5. The PayWay server contacts the issuing bank and requests authorisation for the credit card transaction.
  6. The PayWay server returns the Response to the Customer through the HTTPS connection established in step 1.
  7. The API reads the Response and returns it to the process that initiated the API request.

Depending on the technology used, this process is then can the repeated from step 2 for further Request/Response cycles to process additional credit cards. Refer to your technology specific API document for more details on whether the API object can be re-used for additional transactions.

Provided software

Supported technologies

PayWay provides an API software package for the following technologies:

  • Java
  • Microsoft Component Object Model (COM) and Active Server Pages (ASP)
  • Microsoft .NET
  • PHP

This software API provides an object in the relevant programming language which performs all the communication with the Westpac PayWay server. The objects contain the same methods/functions regardless of the technology, and these are listed below. The method names start with lower case for Java and PHP, and upper case for Microsoft technologies, according to the relevant conventions

Method Name Description Arguments Return Value
initialise Initialise this object so that it can process CCAPI transactions. Configuration information is read from the provided parameters string. parameters - the initialisation parameters (delimited with an ampersand (&)) to use. These parameters must contain at a minimum the log directory and the certificate file. None.
isInitialised Returns true if this client object has been correctly initialised or false otherwise. None. true if this client object has been correctly initialised or false otherwise.
processCreditCard Main credit card processing method. Pass the request parameters into this method, then the current thread will wait for the response to be returned from the server. parameters - The parameters string containing all the request parameters (delimited with an ampersand (&)) to send to the server. The response string containing all the response parameters (delimited with an ampersand (&)) from the server.

Other technologies

If your application does not use one of the supported technologies, there is another option available - SOAP. Using this integration method, you develop your application to send the credit card requests to Qvalent using SOAP. More details about how to do this are provided in the document entitled PayWay API for SOAP which can be downloaded from the PayWay website.

The parameters are still sent and received in the same format as for all other technologies (i.e. one long string containing all request parameters, delimited by an ampersand (&)). Section 3.1.3 on initialising the API will not be relevant to you, but all other sections of this document still apply.

The SOAP method to process a credit card is called processCreditCard and has the same signature and behaviour as described in the table above.

Initialising the API

The Qvalent PayWay API object must always be initialised before it can be used. The object instance should be created in the normal way for your technology, and you must then call the initialise method on this object.

The parameters for the initialise method are listed in the table below.

Name Description Required
logDirectory The directory to place the log files in. If the directory does not exist, it will be created. Yes
certificateFile The location of the file containing your certificate. Use a fully qualified file name including the drive letter and full directory information. Yes
proxyHost The host name of the proxy server that your application must connect through to access the Qvalent PayWay server. Do not include this parameter if you do not require a proxy server. No
proxyPort The port number the proxy server listens on. Do not include this parameter if you do not require a proxy server. No
proxyUser The username required to connect to the proxy server. Do not include this parameter if you do not require a proxy server. No
proxyPassword The password required to connect to the proxy server. Do not include this parameter if you do not require a proxy server. No

Where you store this information in your application is up to you. The best solution is to make this information of your application's standard configuration. For example, if your configuration is stored in an XML file, add this information to that XML file and read it from your application. It is unwise to hard-code values for these parameters in your software, since you may wish to change them in the future.

An example parameters string for the initialise method is

certificateFile=d:\payway\payway.q0&logDirectory=d:\payway

Note that there should be no spaces or line breaks in the parameters string.

Any errors during initialisation will be reported through your technology'''s usual mechanisms (e.g. the Java and .NET objects will throw an exception, the PHP object will raise an error). These errors normally relate to invalid parameters being specified (such as a non-existent certificate file), or invalid system configuration (such as missing required libraries). By default, a 60-second timeout will apply for the initialisation.

Once the object has been initialised, you may call the processCreditCard method to process credit card transactions. It is possible to call processCreditCard multiple times on the same object from multiple threads depending on your technology. Refer to your technology specific API document for more details.

Processing credit card transactions

To process a credit card transaction, your application sends the Qvalent PayWay server a string of request parameters, and it returns you a string of response parameters. Both these strings are of the same format:

  • Each parameter is of the form: name=value
  • Parameters are separated by ampersand characters (&)

The same format applies regardless of whether you are using Qvalent PayWay API software, or the SOAP interface. Only use standard ASCII characters in your parameter values. Do not use any of the following special characters in your parameter values:

  • Ampersand (&) - ASCII character number 38
  • Plus sign (+) - ASCII character number 43
  • Percentage sign (%) - ASCII character number 37

Request parameters

Below are the valid request parameters that your application can provide.

Parameter Name Data Type Description Required
order.type See Description for valid order types The type of processing required:
  • capture
  • refund
  • query
  • echo
  • preauth
  • captureWithoutAuth
  • reversal
  • accountVerification
  • preauthCancellation
Yes
order.authType See Description When sending a preauthorisation transaction, this field may be:
  • initial - a new preauthorisation
  • incremental - top-up a preauth
  • extension - extend the time of the preauth (MasterCard only).
  • reauthorisation - reauthorise a preauth that has expired after the maxiumum timeframe supported by the card scheme (Visa only).
If you send incremental, then you must also send a new order.amount and customer.originalOrderNumber. If you send extension or reauthorisation, then you must also send customer.originalOrderNumber.
No Only allowed if order.type is preauth.
order.cancellationType See Description When sending a preauthorisation cancellation, this field may be:
  • partial
  • full
You must also send order.amount and customer.originalOrderNumber.
Yes if order.type is preauthCancellation
customer.username At most 32 chars The customer's username (from PayWay web site).

The PayWay server uses the username parameter to identify your company within the system.

You will always use the same username and password regardless of which merchant ID you select.
Yes
customer.password At most 32 chars The customer's password (from PayWay web site). Yes
customer.merchant At most 32 chars The merchant ID to use. Enter either TEST for test transactions, or your 8 digit live Westpac merchant ID. Do not use your Amex or Diners merchant ID here. Yes
card.PAN At most 19 chars The credit card number. Only for capture / refund / preauth / captureWithoutAuth / reversal / accountVerification (Alternatively, provide customer.customerReferenceNumber)
card.CVN At most 4 digits The card verification number.

This is a 3 or 4 digit code that provides extra security for online payments.

For Visa, MasterCard, UnionPay and Diners, this is the last 3 digits on the back of the signature panel.

For Amex, this is the 4 digit number on the front of the card above the embossed card number.

Under no circumstances should the CVN be stored in any system.
Optional for capture / refund / preauth / captureWithoutAuth / reversal / accountVerification
card.expiryYear 2 digits The year the card expires. Required for capture / refund / preauth / captureWithoutAuth / reversal / accountVerification (Alternatively, provide customer.customerReferenceNumber)
card.expiryMonth 2 digits The month the card expires - must be between 1 and 12. Required for capture / refund / preauth / captureWithoutAuth / reversal / accountVerification (Alternatively, provide customer.customerReferenceNumber)
card.cardHolderName At most 60 chars The name on the credit card being processed.

Note this is for information only - the card holder name will not be checked by the card issuer. This field will appear on the reports that can be downloaded from the PayWay website.

Note: Do not use any of the following characters in the card holder name: & % +
Optional (Alternatively, provide customer.customerReferenceNumber)
order.amount At most 12 digits The amount to apply to the card based on the order.type in cents. This amount should be a positive value for all order types. For example, enter 1295 for an amount of "$12.95". Required for capture / refund / preauth / captureWithoutAuth / reversal / preauthCancellation. Do not pass an amount for an accountVerification.
customer.customerReferenceNumber At most 20 chars The customer reference number to record against this transaction.

This field will appear on the reports that can be downloaded from the PayWay website.

Only letters, numbers, dashes, underscores and full-stops are accepted in this field.

This field can be provided as an alternative to card.cardHolderName, card.expiryYear, card.expiryMonth, card.CVN and card.PAN if the customer reference number is registered in the PayWay application and has associated credit card details.
customer.orderNumber At most 20 chars Your unique transaction number. This number can be used at a later date to query a transaction. This is your own internal tracking number for this transaction, which can also be used in the PayWay search screens. This number must be used by your systems to prevent duplicate transaction processing.

Note 1: This must be unique for a given merchant id.
Note 2: Do not use any of the following characters in your order number: & % +
Note 3: Include at least one letter or use a maximum of 15 numeric characters to ensure the order number is displayed correctly in Microsoft Excel.
Required for capture / refund / query / preauth / captureWithoutAuth / reversal / accountVerification
card.currency 3 chars The currency to apply to this card transaction.

Always enter 'AUD' for Australian Dollar Payments.

The PayWay API only accepts transactions in Australian Dollars. However, you can charge credit cards from outside Australia. You will receive funds in Australian Dollars. The transaction will appear on the cardholder statement in their currency using an exchange rate determined by the card scheme (Visa, UnionPay, American Express, etc).
Required for capture / preauth / captureWithoutAuth. Optional for refund / reversal. Do not pass a value for accountVerification.
order.ECI 3 chars The Electronic Commerce Indicator (ECI) to apply to this card transaction. Required for capture / refund / preauth / captureWithoutAuth / reversal
customer.originalOrderNumber At most 20 chars This parameter is used when performing a refund to link the refund with the original capture.

Also required when performing a reversal of a preauth/capture. In this case, this parameter must be populated with the original order number of the preauth/capture transaction.

Also used when capturing a previous preauth. In this case, this parameter must be populated with the original order number of the preauth transaction.

Note that this field was previously named customer.captureOrderNumber
Required for refund / reversal / captureWithoutAuth / preauthCancellation. Required for preauth if the preauth type is incremental, reauthorisation or extension.
order.authId 6 chars The authorisation Id returned from the corresponding preauth transaction. This should be the value returned in response.authId for the preauth transaction. Optional for captureWithoutAuth. Must not be present for other transaction types.
order.includedSurchargeAmount At most 12 digits The amount of the order total that is considered to be the surcharge in cents (for example, enter 129 for a surcharge amount of "$1.29").

Only specify this field if you apply surcharges to credit card payments.

This field defaults to 0 if not specified. This amount must be less than the order total.

This field will appear on the reports that can be downloaded from the PayWay website.
Optional Do not pass an amount for accountVerification.
order.ipAddress At most 15 chars The IP address of the card holder performing the transaction (if the transaction is an internet payment).

This field must not be populated for mail, telephone or recurring payments.

This information is used in fraud checking if you have opted for the Fraud Guard module. E.g. 10.101.101.101.
Required for e-commerce transactions.
card.posEntryMode At most 20 chars For Visa and Mastercard only. One of: MANUAL (the card number was manually entered into the system by the cardholder or the merchant) or STORED_CREDENTIAL (the card number is stored by the merchant to process future purchases for a cardholder). Defaults to MANUAL if not specified.
card.storedCredentialUsage At most 20 chars Available for Visa only. Identifies the purpose of a stored card number. One of:
  • INSTALMENT - A transaction in a fixed series of transactions for a single purchase of goods or services.
  • RECURRING - A transaction in a series of transactions that are processed at fixed, regular intervals (not to exceed one year between transactions) for purchase of goods or services provided at regular intervals.
  • UNSCHEDULED_CIT - A cardholder-initiated unscheduled transaction (which does not occur on a scheduled or regularly occurring transaction date).
  • UNSCHEDULED_MIT - A merchant-initiated unscheduled transaction (which does not occur on a scheduled or regularly occurring transaction date). The transaction is initiated by the merchant without active participation of the cardholder (e.g. account top-up).
Only applicable for order.type values capture, preauth, accountVerification and captureWithoutAuth.
No
order.authTraceId At most 15 chars Available for Visa only. Used to identify the previous transaction for the cardholder when using a stored credential. No

3-D Secure

3-D Secure is a mechanism for authenticating the cardholder before processing a transaction. PayWay Classic API does not perform the authentication, but supports the additional fields required for transaction processing. You will need to integrate with third party 3-D Secure Server Software to perform the authentication.

Below are the additional request parameters you must provide for 3-D Secure transactions.

Parameter Name Data Type Description Required
order.ECI 1 digit Electronic Commerce Indicator (eci) from your 3-D Secure Server. Your 3-D Secure Server may provide this as a 2-character value e.g. 05. Strip the leading zero and send a 1 digit value e.g. 5 Yes for capture or preauth 3-D Secure transaction
order.xid 36 chars DS Transaction ID (dsTransID) from your 3-D Secure Server. In the form of a UUID e.g. 30aa950d-4056-444b-bcf6-9a3696805d05 Yes for capture or preauth 3-D Secure transaction
order.cavv 28 chars Authentication Value (authenticationValue) from your 3-D Secure Server. e.g. MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= Yes for capture or preauth 3-D Secure transaction
order.threeDSVersion 5-8 chars Message Version Number (messageVersion) from your 3-D Secure Server. In the form x.y.z e.g. 2.1.0 Yes for capture or preauth 3-D Secure transaction
Aggregator merchant soft descriptors

If you are an aggregator merchant, these parameters allow you to provide a soft descriptor field to identify the sub-merchant.

If you are not an aggregator merchant, do not send these fields.

Parameter Name Date Type Description Required
customer.merchantName At most 22 chars Must be in the form: Aggregator Name*SubMerchantName Yes for aggregator merchants.
customer.merchantStreetAddress At most 48 chars The street address of the sub-merchant's trading address. Yes for aggregator merchants.
customer.merchantLocation At most 13 characters The city or suburb of the sub-merchant's trading address. Yes for aggregator merchants.
customer.merchantState At most 3 characters. The state of the sub-merchant's trading address. One of NSW, ACT, VIC, QLD, NT, SA, WA, TAS. Yes for aggregator merchants.
customer.merchantCountry At most 2 characters Must be set to AU Yes for aggregator merchants.
customer.merchantPostCode At most 4 characters The postal code of the sub-merchant's trading address. Yes for aggregator merchants.
customer.subMerchantId At most 15 digits A unique identifier for your sub-merchant, allocated by you. Yes for aggregator merchants.

Response parameters

Below are the possible response parameters that the PayWay server can send back to your application. Note that PayWay may add additional parameters to the response at any time, so you should not assume that these will be the only parameters that are present in the future.

Parameter Name Date Type Description Always Present
response.summaryCode number The summary code in numeric format. 0 - Approved, 1 - Declined, 2 - Erred, 3 - Rejected. Yes
response.responseCode 2 chars The AS2805 response code of the transaction. Yes
response.text String (At most 200 characters) A textual description of the transactions response or failure. Yes
response.settlementDate yyyymmdd The settlement date for the transaction. Returned when the transaction is stored in the PayWay database. Returned for all approved transactions and most declined transactions.
response.receiptNo String (At most 32 characters) Internal PayWay reference number for transaction. Returned for all approved transactions and most declined transactions.
response.cardSchemeName String (At most 20 characters) This is the card scheme of the card used in the transaction. AMEX, DINERS, MASTERCARD, VISA, UNIONPAY. Only if card scheme is known
response.creditGroup String (At most 20 characters) This is the card scheme grouping of the card used in the transaction. AMEX, DINERS, VI/BC/MC. Only if the card scheme is known.
response.transactionDate dd-mmm-yyyy hh24:mi:ss The date/time the transaction occurred. Only if transaction passes initial parameter checks.
response.authId String (At most 6 characters) The authorisation Id returned from the issuing bank for preauth transactions. This value must be passed in with any subsequent captureWithoutAuth transaction for the same card. Only for approved preauth transactions.
response.authTraceId 15 chars Returned by Visa and Mastercard to identify the lifecycle of a preauth or purchase. In most cases you can ignore this field. No

API examples

Request Parameters Example

customer.username=Q00000&
customer.password=Ahl2jfi8n&
customer.merchant=TEST&
order.type=capture&
card.PAN=4564710000000004&
card.CVN=847&
card.expiryYear=19&
card.expiryMonth=02&
order.amount=1000&
customer.orderNumber=1136346832577&
card.currency=AUD&
order.ECI=SSL

The above parameters string has been split at the ampersand & markers for readability. When you construct your parameters string, you should not include any spaces or line breaks.

Response Parameters Examples

response.summaryCode=0&
response.responseCode=08&
response.text=Honour with identification&
response.receiptNo=505228832&
response.settlementDate=20060125&
response.transactionDate=25-JAN-2006 14:09:49&
response.cardSchemeName=VISA&
response.creditGroup=VI/BC/MC

The above parameters string has split at the ampersand & markers for readability. The response parameters you receive will not contain these extra line breaks.

Further details

API request

Using Recurring Billing and Customer Vault to hold credit card details

If you have both the PayWay API and Recurring Billing and Customer Vault modules, you can:

  • register a customer number and associated credit card details via a web page or via the API,
  • charge the customer by passing the customer number and amount using the Application Programmer Interface (API).

Your software has full control over transaction processing without needing to store credit card details. This solution can potentially reduce your obligations under Payment Card Industry Data Security Standards (PCI DSS) compliance.

When the card-holder registers his/her credit card details using the Recurring Billing and Customer Vault module, the details are recorded against a customer reference number that you supply. The customer reference number must be unique - each card-holder may only register one credit card.

Customers can be registered by you. Sign in to PayWay and click Add Customer under the Customers menu item.

Alternatively, you can have them self-register on a Westpac hosted web page (See Internet Sign Up for Recurring Billing in the PayWay User Guide, which is available from the Downloads section of the PayWay website).

Alternatively, customers can be registered via the API.

A list of registered customers can be found by signing in to PayWay and selecting Search and Edit under the Customers menu item.

To use the pre-registered cardholder information, use the following parameters:

  • order.type - capture, preauth, refund, captureWithoutAuth, reversal (cardholder details are not required for other order types)
  • card.PAN, card.expiryYear, card.expiryMonth, card.CVN - these parameters must not be present, otherwise the pre-registered account will not be used
  • customer.customerReferenceNumber - the unique reference number for the pre-registered customer
  • customer.merchant - optional since the customer is registered against a merchant
  • other parameters as normal

If the card-holder's details cannot be located, a QA Invalid Parameters response will be returned. Otherwise, the response you receive will be the same as if you had specified the card details yourself.

Electronic Commerce Indicator

The Electronic Commerce Indicator (ECI) is used by acquirers/issuers to determine the type of transaction being processed. The ECI value should represent the source of the transaction request. That is, the environment that the cardholder used to provide the payment card details to the merchant. It is important that merchants set the correct ECI value during transaction processing to ensure that appropriate merchant service rates are received.

An Electronic Commerce Transaction is one where the cardholder enters their card details into a merchant's website, and the transaction is processed immediately. According to Card Scheme rules, merchants must collect the Card Verification Number (CVN) for all electronic commerce transactions. This means that if you provide an ECI value from the table below that represents an Electronic Commerce Transaction, you must also provide the CVN in the card.CVN parameter.

Note: PCI DSS requires that the CVN must never be stored in any card processing system.

ECI Value Description Electronic Commerce Transaction
CCT Call Centre Transaction No
IVR IVR Transaction No
MTO MOTO Transaction No
SSL Channel Encrypted Transaction (SSL or other) Yes
REC Recurring payment. No
5 3D Secure transaction.

This is the value returned from your 3-D Secure Server software for 3D Secure transactions. The numeric ECI values are only available when the transaction contains the 3D Secure order.xid, order.cavv and order.threeDSVersion fields. Depending on your 3-D Secure Server software, you may need to convert the MasterCard ECI values to the Visa ECI values depicted above.
Yes
6 3D Secure transaction. Yes
7 3D Secure transaction. Yes
Stored credential transactions

When processing an initial stored credential purchase for Visa, send the following additional request parameters:

Parameter Name Value
card.posEntryMode MANUAL
card.storedCredentialUsage Identify the intended usage of the stored card number using INSTALMENT, RECURRING, UNSCHEDULED_CIT or UNSCHEDULED_MIT.

Store response.authTraceId for use in future transactions.

When processing subsequent purchase with a stored credential for Visa, send the following additional request parameters:

Parameter Name Value
card.posEntryMode STORED_CREDENTIAL
card.storedCredentialUsage Identify the purpose of this transaction using one of INSTALMENT, RECURRING, UNSCHEDULED_CIT or UNSCHEDULED_MIT.
order.authTraceId The value returned in the response.authTraceId for the previous transaction using this stored credential
Refund orders

Refunds are always matched against an original capture using the originalOrderNumber parameter. The original order number will be checked to ensure that it was an approved Capture. Finally, the refund will be checked to determine if the amount is less than or equal to the original capture less other approved refunds against the same capture. If all of these checks are passed, the transaction will be processed as per normal. If any of the checks fail, a 'QV' response will be returned with response text differing based on which condition failed.

Although all parameters should be supplied as per normal, the following includes an explanation of the key API parameters required for a refund against an original capture:

  • order.type = refund
  • card.PAN, card.expiryYear, card.expiryMonth - if supplied they must match the details given on the original capture. If they are not supplied then the values given in the original capture will be reused.
  • order.amount - amount being refunded, must not exceed amount originally captured
  • customer.orderNumber - new, unique transaction reference for the refund (i.e. a different value from the order number used for the original capture)
  • customer.originalOrderNumber - order number of original capture
Query orders

In order to execute a 'query', the request must include:

  • order.type=query
  • your identification details (customer.username, customer.password and customer.merchant)
  • customer.orderNumber of the order that you are querying

For most transactions, the response will include the previously returned response code. However, if this was previously a summary code of 2 (ie Transaction Erred), the API will attempt to determine an updated response code for the transaction if available. Since order numbers are only unique per merchant, make sure you are using the same merchant ID as for the original transaction.

If you perform a query and receive a Q2 response, the original transaction is still being processed. You should re-attempt the query after 60 seconds.

When executing a Query order, it is important to note that it is possible that the response code indicates a failure with the query itself rather than the original transaction itself. For example, the original transaction may have been successful, but the subsequent query fails due to a network issue. If this has occurred, a QI is returned for the query.

One special case for queries is that a QG is returned if the order number supplied is unknown. This may occur if your system has attempted a transaction that failed prior to being attempted (e.g. network issues between your server and PayWay). In this case, the original transaction was not attempted, and can be safely retried if required.

Echo orders

The Echo order type allows your application to interrogate the status of the API server. If you include order.type=echo, a response code of 00 will be returned if the PayWay server is accessible. This is essentially a network test from your server to PayWay. However, this does not confirm that your merchant account is available.

Preventing duplicate payments

When implementing the API, it is your responsibility to ensure that your application prevents customers from performing duplicate payments. However, the following is provided as a guide of best practices to avoid duplicate payments.

Firstly, the most common causes of customers performing duplicate payments via ecommerce applications are:

  • Customer double-clicks on Make Payment button on web application, and the payment is executed twice.
  • Customer does not wait sufficient time for the transaction response to be returned, and they retry the transaction.
  • Due to a system or network issue, the customer does not receive a response from your system, and they retry the transaction.

In each case, safeguards can be put in place which virtually eliminate duplicate payments.

With the API, it is important to remember that the customer.orderNumber must be unique for each distinct transaction attempt. This means that if a transaction is retried with the identical customer.orderNumber, it will only be processed once (any further attempts will be rejected with a Q6 Duplicate Transaction response). However, if transactions are submitted with the same details except with a different customer.orderNumber, they will both be processed.

The following recommendations should be considered when designing your application to prevent duplicate payments:

  • If providing a web or screen interface, ensure that the Make Payment button can only be clicked once and double-clicking will not attempt two transactions.
  • Prior to executing an API transaction, commit this to permanent storage in your system in a pending state. When the response is returned, update the details with the response. If there is a network failure mid-transaction or your application crashes, you may then later use the Query operation to determine the success or failure of the first attempt.
  • Once a customer has confirmed that they wish to pay, check if you have any approved (summary code 0), pending or incomplete (summary code 2) transactions for the same customer number, credit card number and amount within a recent time period (e.g. 24 hours). If you do find a match, inform the customer of the situation (e.g. Possible duplicate payment attempt. Please check your statement and confirm whether transaction has been processed before retrying.) but optionally give them the opportunity to proceed with executing the payment if they wish.

API response

System times

All times are based on Sydney time. This is either Australian Eastern Standard Time (AEST) or Australian East Daylight Time (AEDT) depending on the time of year.

Settlement date

The settlement date represents the date that the transaction will be settled by the acquiring bank. The settlement date cut-off is always 6pm. If you process transactions after this time, the settlement date will be the following day.

For example, if you process a transaction at 7pm on 24 Jan 2006, the settlement date will be 25 Jan 2006 (represented as 20060125 in the response).

Furthermore, the settlement date does not necessarily mean that the funds will be credited on the settlement date returned. Again, this is up to the relevant acquiring bank. However, for reconciliation purposes, all successful transactions through a given acquirer that return the same settlement date will be credited together on the same day.

Westpac/St. George credits your account the same day, except on weekends and public holidays when the settlement is delayed until the next banking day. The amount credited is the total of approved transactions. Any merchant service fees will be deducted as separate transactions per your service agreement.

American Express and Diners Club may credit your account a number of days later and may be a net amount (ie approved transactions less the merchant service fees), depending on your contract with them. Although Westpac/St. George facilitates the processing of the transaction, we do not control settlement for these schemes and therefore any queries should be made to American Express and Diners Club directly.

The settlement date will be returned for all approved transactions. It will often be returned for declined transactions but not all declined transactions. It will be returned only if the transaction is stored in the PayWay database, but not transactions rejected prior to this (for example: QJ - Incorrect Customer Password).

For customers receiving a transaction log, the settlement date may be used to reconcile the log with your own records.

CVN response

If you provided a Card Verification Number (CVN) with the transaction request, the issuing bank will generally return a special CVN response field indicating whether the CVN was correct. This value can assist you in determining why a transaction was declined.

The table below lists the common values and their meanings. Note that the issuing bank may potentially return some other CVN response code not listed, or may not return a CVN response at all.

CVN Response Description
M Matched (i.e. the CVN is correct)
N Not Matched (i.e. the CVN is incorrect)
P Not Processed (i.e. the CVN was not processed for some reason - do not assume that the CVN is necessarily correct)
S Suspicious
U Unknown (i.e. the CVN was not processed for some reason - do not assume that the CVN is necessarily correct)

The recommended procedure for using the CVN response is as follows:

  1. If the transaction is approved, you do not need to check the CVN response.
  2. If the transaction is declined, check if the CVN response is N or U. If so, inform the cardholder that they provided the incorrect CVN.
  3. Otherwise, ask the cardholder to confirm that they entered all their card details correctly. If all the card details are correct, ask the cardholder for an alternative form of payment.

Under no circumstances should the CVN be stored in any system.

Card Scheme vs Credit Group

In order to aid reconciliation, the API response includes details on the cardScheme and creditGroup. The differences between these two parameters are explained below.

Every transaction will be using a card from a particular card scheme, such as Amex or Visa. However, the creditGroup indicates which transactions will be grouped together in a single credit to the customer's bank account. This occurs for Visa, Mastercard and UnionPay transactions where Westpac will group all such transactions into a single credit. However, Amex and Diners will be credited separately.

The following table summarises the relationship:

cardScheme creditGroup Acquiring Bank
AMEX AMEX American Express
UNIONPAY VI/BC/MC Westpac/St. George
DINERS DINERS Diners Club
MASTERCARD VI/BC/MC Westpac/St. George
VISA VI/BC/MC Westpac/St. George

Pre-authorisations

Most of the transactions you perform using the Credit Card API will be capture transactions. These transactions are equivalent to a purchase using an EFTPOS device (i.e. someone in a shop purchasing something and paying by credit card).

Behind the scenes, a capture is made up of two parts: a pre-authorisation, and a clearance. The pre-authorisation is the message that is sent to the issuing bank to check whether the transaction can be processed (i.e. the card number is correct, and the account has enough funds etc). Once the pre-authorisation transaction is approved, the clearance is sent and at the end of the day, the transaction will appear on the cardholder's statement. The pre-authorisation can be thought of as reserving the funds, and the clearance can be thought of as a trigger message that causes the actual transaction to take place.

Capture transactions consist of these two parts, and they happen seamlessly to the API user. However, the API allows customers to split the process into its two separate components when this is required by a customer's business model. This is the purpose of the preauth and captureWithoutAuth transactions. The preauth transaction reserves the funds, and the captureWithoutAuth transaction adds the transaction to the list of clearances that will occur at the end of the day.

An example usage would be if a company had separate order processing and shipping systems. The order processing system could first check the available funds using the preauth transaction, and then send the order to the shipping system. When the goods are ready to be shipped, the order processing system would send the captureWithoutAuth transaction to complete the purchase. Separating these two functions allows for the case where the goods are out of stock, or discontinued, since no money has been taken from the cardholder's account.

An important consideration is the length of time that a pre-authorisation will last. This time depends solely on the issuing bank and cannot be controlled by Westpac. Most issuers will keep the funds reserved for at least three banking days. You should certainly not assume that you can safely perform a preauth then perform the captureWithoutAuth 4 weeks later.

This short lifetime of pre-authorisations is the main reason that most companies do not use this feature. Most companies interested in pre-authorisations have a much longer time between ordering and shipping (such as several weeks). The danger in sending the captureWithoutAuth after the preauth has expired is that the issuing bank will raise a charge back for the transaction.

Each pre-authorisation is given an identifier by the issuing bank so that the capture can be matched to the reserved funds. To ensure that this matching occurs, you must specify the order number of the preauth transaction in the customer.originalOrderNumber parameter for the captureWithoutAuth transaction request. You must generate a new order number for the captureWithoutAuth transaction.

Performing pre-auth transactions

To perform a preauth transaction, use the following request parameters:

  • order.type = preauth
  • customer.orderNumber - unique transaction reference for the pre-authorisation
  • All other fields as normal

To perform a captureWithoutAuth transaction, use the following request parameters:

  • order.type = captureWithoutAuth
  • card.PAN, card.expiryYear, card.expiryMonth - not present. You are not required to store card details.
  • customer.orderNumber - new, unique transaction reference for the captureWithoutAuth (i.e. a different value from the order number used for the original pre-authorisation)
  • order.authId - not present
  • order.amount - the amount to charge the card-holder
  • customer.originalOrderNumber - order number of original preauth transaction

Remember:

  1. You must perform a captureWithoutAuth transaction to complete the purchase. If you do not, the funds will not appear in your account.
  2. You cannot perform a captureWithoutAuth without a corresponding preauth.
  3. Pre-authorisations do not last for very long (typically around 3 days).
  4. The preauth and captureWithoutAuth transactions must have unique order numbers in the customer.orderNumber parameter.

Reversals

Each capture transaction comprises two parts behind the scenes. Since the transaction value does not actually appear on the cardholder's statement until the end of that day, it is possible to cancel, or reverse, a transaction before it is cleared. Declined transactions do not need to be reversed.

The cut-off time for reversals is 6pm EST each day. For example, the settlement day of 25 Jan 2006 starts at 6pm on 24 Jan 2006, and ends at 6pm on 25 Jan 2006. Thus, any transaction processed with during the 25 Jan 2006 settlement day can be reversed until 6pm 25 Jan 2006. You cannot reverse any such transactions after this time. Instead, you should perform a refund if the original transaction was a capture, or perform a capture if the original transaction was a refund.

To reverse a transaction, you create the request message and specify the order type as "reversal". You must also place the order number of the transaction you wish to reverse in the original order number parameter. You should also specify the card number and expiry date of the original transaction if you have them since extra checking of the transaction will be performed in this case.

Below are the details of the parameters for a reversal transaction:

  • order.type=reversal
  • card.PAN, card.expiryYear, card.expiryMonth, order.amount - if supplied they must match the details given on the original transaction. If they are not supplied then the values given in the original transaction will be reused.
  • customer.orderNumber - new, unique txn reference for the reversal
  • customer.originalOrderNumber - order number of original transaction (capture, refund or preauth)

You may reverse capture, refund or pre-authorisation transactions. If you attempt to reverse any other transaction type, you will receive an error response.

If the reversal succeeds, a response code of 00 will be returned, and the response code of the original transaction will be updated to 91. If you attempt to query the original transaction, or view it through the administration screens, this is the status that you will see. Your software should also update the response code of the original transaction to 91 for consistency.

Because of the limited time you have to reverse a transaction, the main use of reversal transactions is to ensure that both your system, and the PayWay system have a consistent status for a transaction. For example, if you perform a capture and before you receive a response, a network error is encountered, you could then reverse the original transaction so that both systems mark the transaction with a 91 response code.

The following table lists the various reasons that a reversal will not be accepted, and the response code you can expect to receive in that situation.

Situation Response Received
Original transaction not found, i.e. no transaction with the specified original order number exists in the system. 21 - no action taken
Original transaction was not approved, i.e. the original transaction had a summary code other than 0. 21 - no action taken
Original transaction is not reversible, i.e. a reversal was submitted for a transaction that was not a capture, captureWithoutAuth, refund or preauth. 12 - invalid reversal
Reversal details do not match original transaction details, i.e. different card details were specified in the original transaction and the reversal 12 - invalid reversal
Current Settlement date is not the same as the original transaction, i.e. the original transaction's settlement date is different from the current system settlement date 12 - invalid transaction
Original transaction was already reversed, i.e. a reversal was submitted for a transaction that had previously been reversed 00 - approved or completed successfully
Reversal accepted, i.e. a valid reversal was submitted and processed 00 - approved or completed successfully
Error occurred during processing QE - Internal Error
Communications error occurred between client and PayWay server QI/QX - Incomplete or Network error

Processing these response codes is relatively simple.

  • If the response is 00 or 21, then either the transaction has been reversed, or does not need to be reversed.
  • If the response is 12, you should check the details of the transaction you are trying to reverse. For example, you may be specifying the wrong original order number.
  • If you receive a QE, QI or QX response or a network error, you should re-attempt your reversal.

Error handling

The API will inform your system of any errors that occurred in the processing of the credit card request. Error information will be returned in summary form in the response.summaryCode and a detailed description of the error in the response.responseCode and response.text. As in most software, much of the code you write will be to handle error conditions that occur infrequently.

You can think of your system like a physical EFTPOS terminal. A terminal transactions on behalf of a user and displays the response. It must also deal with error conditions like communications link failures. Where a response is received, the response.summaryCode may be used to determine the appropriate system behaviour. Recommended system actions based on these responses is included in the following table.

Summary Code Description Recommended System Action
0 Transaction Approved Transaction is successful. No further action required.
1 Transaction Declined Transaction has been declined by the financial institution. Some of the more common reasons are invalid credit card details (QQ), expired card (54) or insufficient funds (51). In many cases, the problem can be addressed by either:
  • Carefully checking the card details and correcting any mistakes before retrying under a new orderNumber; or
  • Retrying the transaction under a new orderNumber with an alternative card of the card holder.
The reason for the decline may not always be obvious from the detailed response code eg Do Not Honour (05). In this case, ask for an alternative means of payment from the card holder.
2 Transaction Erred Transaction is of an unknown status. Please refer to section below for details on how to handle this status.
3 Transaction Rejected Transaction request has been rejected by the Westpac Credit Card API, often due to invalid parameters or system configuration. This is similar to the Transaction Declined (Summary Code of 1) in terms of error handling. Refer to the detailed response code and either:
  • Correct the transaction details if required and retry under a new orderNumber; or
  • Handle offline through PayWay CustomerCare if you are unable to resolve the issue.

Summary Code 2 - Transaction erred

When implementing the API, you should take care to correctly handle summary code 2 responses. In an ideal world, all transactions would simply succeed or fail. Unfortunately, certain circumstances can mean that your system will not know the status of the transaction. For example, a transaction may be received and processed by PayWay, but a network error may occur such that a response is not returned to your system. In this case, your system will receive the "Transaction Erred" summary code or some other network/timeout error. The network outage may last for some time and therefore your exception handling process must handle this rare but possible situation.

When this situation arises in the EFTPOS world, the terminal performs the following actions:

  1. The terminal records the transaction as declined and informs the merchant and cardholder of the declined status
  2. A reversal message is sent to the bank to ensure that the transaction never takes place

Your system needs to perform these same actions to ensure that the payment status is always known. In addition to these actions, your system should alert your support staff that a network error has occurred so that they can investigate the root cause. If they cannot identify the cause of the issue and the issue is ongoing, they should contact PayWay customer care.

Firstly, your system should record the transaction status as 91 "Issuer or switch inoperative". This status should also be presented to the person using your system (e.g. the cardholder or one of your operators).

Secondly, your system must ensure that the transaction is reversed. You have two options to accomplish this:

  1. Your system can queue the reversal and keep sending it to PayWay until it is successful.
  2. Your system can inform an operator that a transaction must be reversed, and they can manually perform the reversal through the screens available on the PayWay website.

The manual option makes your system development simpler, but makes your support processes more complicated. In either case, you must record the order number of the original transaction for future reference. Pseudo-code for both options is provided below.

Manual reversing

ccResponse=processCreditCard('capture'/'refund',other API parameters)
  if ccResponse.summaryCode!='2'or network error
  // This is the normal condition - transaction attempt is complete
  Store transaction response and handle response
  else
  {
  // Transaction status is unknown
  Store transaction status as'91'
  Alert support personnel to perform a manual reversal
  Alert support personnel to investigate network connectivity
  }

Your support personnel will search for the transaction by order number, so ensure that the order number is included in the alert that is sent to them.

Building a system to reliably reverse a failed transaction can be a complex task. You will need to permanently store a record to indicate that the transaction requires reversing. These records need to be added to a reversal queue and this queue must be processed by a separate background thread in your application. When a reversal is successful, your system will update the reversal record accordingly and remove it from the reversal queue. You will also need to ensure that when your system starts up, any outstanding reversal records are added to the queue.

Automatic reversing

// Initial transaction attempt
ccResponse=processCreditCard('capture'/'refund',other API parameters)
  if ccResponse.responseCode!='2'or network error
  // This is the normal condition - transaction attempt is complete
  Store transaction response and handle response
  else
  {
  // Transaction status is unknown
  Store transaction status as'91'
  Alert support personnel to investigate network connectivity
  Store reversal and add to reversal queue
  }

The reversal queue processing logic is below:

Repeat
  Wait 60seconds
  Remove next reversal from the queue
  ccResponse=processCreditCard('reversal',other API parameters)
  if ccResponse.responseCode='12'(invalid transaction)
  // Reversal details are incorrect
  Record that reversal failed
  Alert support personnel that reversal cannot be completed
  else if ccResponse.responseCode='00'or ccResponse.responseCode='21'
  // Reversal was successful
  Record that reversal was successful
  else
  // Reversal must be retried
  Add this reversal back on to the queue
  End Repeat

When creating the reversal request, you must include the order number of the original transaction. The reversal record that you store should include this information.

Registering customers

This section provides information on using PayWay API to register, manage and deregister credit card customers. This feature requires that you have both the API and Recurring Billing and Customer Vault modules.

Creating or updating a customer

To register a new credit card customer or modify an existing customer, you must provide the following parameters in your request.

All parameters are mandatory unless otherwise noted.

Parameter Name Value
order.type registerAccount
customer.username As described in API Request Parameters.
customer.password
customer.merchant
customer.customerReferenceNumber The unique reference number for the pre-registered customer. To create a new account, provide a new customer reference number. To modify an existing account, provide an existing customer reference number.
card.PAN The card number to register against this customer reference number
card.expiryYear The expiry date for this credit card
card.expiryMonth
card.cardHolderName The name on the credit card (optional)

The response will contain one of the following response codes:

Response Code Description
00 The customer has been registered in PayWay for future use in credit card transactions.
QE A system error occurred while registering the account. The customer has not been saved and can be registered again later.
14 The card number provided does not pass the check digit routine.
QY Your PayWay facility does not accept this card type.
54 The expiry date provided is in the past.
QA Invalid parameters were provided in your request. See the response text for more information.

Transacting with registered customers

The registered credit card details can be used in any of the following processing requests:

  • capture
  • refund
  • preauth
  • captureWithoutAuth
  • reversal
  • accountVerification

To use the registered card details, you must provide the parameter customer.customerReferenceNumber. This field can be provided as an alternative to card.cardHolderName, card.expiryYear, card.expiryMonth, card.CVN and card.PAN.

Stopping remaining payments

To stop remaining payments for a registered customer, you must provide the following parameters in your request.

All parameters are mandatory.

Parameter Name Value
order.type deregisterAccount
customer.username As described in API Request Parameters.
customer.password
customer.merchant
customer.customerReferenceNumber The unique reference number for the pre-registered customer. To create a new account, provide a new customer reference number. To modify an existing account, provide an existing customer reference number.

The response will contain one of the following response codes:

Response Code Description
00 The customer has had remaining payments stopped in PayWay and cannot be used in future credit card transactions.
QE A system error occurred while stopping the customer's remaining payments. Check that the customer reference number has actually been registered in PayWay previously.
QA Invalid parameters were provided in your request. See the response text for more information.

Dealing with QI responses

A QI response from the API most often indicates that there was a network error between your server and the PayWay server.

Your server cannot know the transaction status because either the request did not arrive at the PayWay server, or the response did not make it back to your server.

If you have followed the recommendations in Error Handling your software should correctly handle the QI response code using one of the following options:

  1. Reversing the transaction via the API to ensure that the card holder is not debited (see Reversals), or
  2. Raising an alert for your support staff to handle

Your support staff can always determine the final status of the transaction using the search pages in the PayWay website. Depending on your business procedures, your support staff can either enter this status into your system, or can void the transaction through the PayWay pages. If a transaction does not appear on these pages, the transaction was not received or processed by the PayWay server.

Network errors can be almost impossible to investigate after the fact, so it is vital that you investigate while you are experiencing an issue. You should try these steps:

  1. If you use a proxy, check that your proxy settings are correct, and check that there are no other issues with your proxy server.
  2. If you do not use a proxy server, login to your server and telnet to www.payway.com.au (for Westpac customers, payway.stgeorge.com.au for St. George customers) on port 443. Record the results of this test for use by your network administrator.
  3. Contact your network administrator and ask to investigate the issue. The results of the telnet test can help to begin the investigation.
  4. If you still cannot locate the cause of the QI responses you should contact PayWay support for assistance. Your network administrators will need to be available to work through the problem with the PayWay network administrators.
Disclaimer

The information contained in this publication is provided for learning purposes only and is subject to change. Revisions may be issued from time to time that encompass changes or additions to this module.

This is a guide only and it is not comprehensive. It does not impinge on or overrule any formal arrangement you may enter into with the Bank. The Bank and its officers shall not have any liability for any losses of any kind incurred in connection with any action, inaction or decision taken in reliance on the information herein or for any inaccuracies, errors or omissions. In this publication references to the "Bank" are to Westpac Banking Corporation ABN 33 007 457 141 and to any of its operating Divisions, including BankSA and St.George.