QuickVoice

QuickVoice is a Westpac service that enables phone payments for your business.

Overview

The key features of the solution are:

  • QuickVoice accepts credit card payments via phone.
  • QuickVoice validates payment details by inspecting outstanding invoices or using adhoc check-digit routines.
    • QuickVoice deducts paid amounts from outstanding invoices.
    • QuickVoice validates ad-hoc payments using your check-digit routine.
    • Upload your invoices to QuickVoice for reference during the payment process.
  • Westpac’s professional voice artist records your customised phone prompts each month.
  • QuickVoice integrates with QuickStream’s suite of receivables products.

How does the payment process work?

The payment process involves the following steps:

  1. Provide the customer with an invoice or bill to pay. This will include details of your phone payment service.
  2. The customer dials your 1300 number to access your phone payment service.
  3. The customer enters their customer reference and/or invoice number.
  4. The customer enters their credit card details, reviews, and confirms the payment.
  5. If the customer needs help with the system, we can provide pre-recorded help dialogue. QuickVoice can also forward to your 1800 help desk number.
  6. If you have uploaded an invoice file, QuickVoice will deduct the paid amount. You choose if full payment is required, or partial payments are allowed.
  7. QuickVoice takes the the payment.
  8. QuickVoice can send a payment notification to your web server.
  9. At the end of the day, QuickVoice provides all payments made to you as a CSV, or in your desired report format.

Implementation Process

There are a number of tasks involved in implementing a QuickVoice solution. Each task is described in detail in the following sections of this document. A summary of the tasks and their corresponding section number is listed in the table below.

Step Description/Documentation Reference
Step 1 Kick-off Meeting
Step 3 Branding QuickVoice
Step 4 Receiving payment details
Step 5 Testing
Step 6 Sign off
Step 7 Production lodgement
Step 8 Go live
Step 10 Post implementation

To help with the implementation process, we have included a requirements checklist for you to complete as you work on each task. The purpose of the requirements checklist is to help identify and keep track of your requirements.

If you require further assistance, please contact your Westpac Implementation Manager or your Qvalent implementation manager.

Kick-off meeting

The kick-off meeting is the first meeting between your organisation and Qvalent. This typically consists of a telephone conference with the relevant people from your organisation, Westpac and Qvalent.

The purpose of this meeting is to, introduce the team members from each organisation, discuss the implementation process and discuss your requirements.

Branding QuickVoice

During your QuickVoice implementation you will be asked to customise the prompts that your customer will hear.

QuickVoice Base Prompts

Once you have determined your phone prompts, change the QuickVoice Base Prompts document.

Download the QuickVoice Base Prompts.

You can then send it to us:

  • Highlight any modified prompts in red.
  • It is important to detail special word and acronym pronunciations.
  • Westpac submits the prompts for recording on the 20th day of each month. If the 20th day is a weekend or public holiday, Westpac submits the prompts on the next business day.
  • Sometimes it is necessary to expedite the recording process. In some cases, Westpac can arrange an unscheduled session to record your prompts.
  • Approximately one fortnight after submission the prompts will be available for review. Westpac provides you with a phone number to use on our test payment server.
  • Once tested and approved, the prompts are then submitted for activation on the live payment server.

QuickVoice Prompt Flowchart

The following flowchart depicts the basic voice prompts played during a typical card payment. The entities and arrows highlighted in green follow a successful transaction scenario. This flowchart is not comprehensive. It is intended to depict the typical prompt flow for QuickVoice.

Download the Flowchart.

QuickVoice Prompt Flowchart

Receiving payment details

There are two ways to receive payment details:

  1. Server to server notification.
  2. Cash Applied File.

Server to server notification

This option is also known as the server-to-server postback. It allows you to receive payment summary details after each credit card payment is made.

This is done via a HTTPS POST to your server. The payment details are posted as form parameters or as XML.

To receive a server to server notification

  1. Your website must provide the serverReturnUrl parameter in a secure token handoff, or configure your server to server notifications in QuickStream Portal.
  2. Configure the domain white list in QuickStream Portal.
  3. Have a valid SSL certificate issued by a trusted certificate authority. Sending the notification over SSL ensures that the encrypted notification cannot be read by a malicious third-party. As your SSL certificate was issued by a trusted certificate authority, it also guarantees that QuickStream is connecting to your webserver (and not another fraudulent server as in the case of DNS attacks).
  4. Have a dynamic backend which can receive and parse HTTPS requests with parameters or can parse XML.

A server to server notification is sent after a successful credit card payment attempt.

When you receive a server to server notification, your system must:

  1. Check that the IP address matches the expected QuickStream IP address.
    • If they do not match you will return a status of 403 Forbidden.
    • See IP addresses in Test and in Production.
  2. Check that the Basic Auth username and password in the Authorization header match your credentials in QuickStream.
    • If they do not match you will return a status of 403 Forbidden.
  3. Extract the payment summary details.
    • The way you do this will depend on the content type the payment details are posted in. You will either extract the details from the form parameters or extract the details from the XML.
  4. Check to make sure you have not already processed a notification for this payment.
    • To do this you will compare the receiptNumber to the receipt numbers you have already processed.
  5. Save the payment details to your database.
  6. Your server returns a status of 200 OK.
    • Note, if an error occurred and you were unable to save the payment details, your server will instead return a status of 500 Internal Server Error.

Example server to server notification consumption in Java

public class NotificationConsumer extends HttpServlet 
{
    ...
    @Override
    protected void doPost( final HttpServletRequest request, 
                           final HttpServletResponse response ) throws IOException
    {
        try 
        {
            if( !request.getRemoteAddr().equals( QUICKSTREAM_IP_ADDRESS ) ) {
                response.sendError( HttpServletResponse.SC_FORBIDDEN );
                return;
            }
            final String authorization = request.getHeader( "Authorization" );
            if( authorization == null )
            {
                response.sendError( HttpServletResponse.SC_UNAUTHORIZED );
                return;
            }
            String base64Credentials = authorization.substring( "Basic".length() ).trim();
            String credentials = new String( Base64.getDecoder().decode( base64Credentials ), Charset.forName( "UTF-8" ) );
            final String[] values = credentials.split(":",2);
            if( !QUICKSTREAM_USERNAME.equals( values[0] ) || !QUICKSTREAM_PASSWORD.equals( values[1] ) )  {
                response.sendError( HttpServletResponse.SC_FORBIDDEN );
                return;
            }
            response.setStatus( HttpServletResponse.SC_OK );
            for( final String name : request.getParameterMap().keySet() ) {
                for( final String value : request.getParameterMap().get( name ) ) {
                    // Consume
                }
            }
        }
        catch( final Exception e  ) {
            response.sendError( HttpServletResponse.SC_INTERNAL_SERVER_ERROR );
        }
        return;
    }
}

Example server to server notification consumption in PHP

<?php
    header( "Content-Type: text/plain" );
    if ( $_SERVER["REMOTE_ADDR"] != QUICKSTREAM_IP_ADDRESS ) {
        header("HTTP/1.1 403 FORBIDDEN");
        return;
    }
    if ( !isset($_SERVER['PHP_AUTH_USER'] ) || !isset( $_SERVER['PHP_AUTH_PW'] ) ) {
        header("HTTP/1.1 401 UNAUTHORIZED");
        return;
    }
    if ( $_SERVER['PHP_AUTH_USER'] != QUICKSTREAM_USERNAME || $_SERVER['PHP_AUTH_PW'] != QUICKSTREAM_PASSWORD ){
        header("HTTP/1.1 403 FORBIDDEN");
        return;
    }
    if( $_SERVER["REQUEST_METHOD"] === "POST" ) {
        try {
            foreach( $_POST as $key => $value ) {
                // consume
            }
            header("HTTP/1.1 200 OK");
        } catch (Exception $e) {
            header("HTTP/1.1 500 INTERNAL SERVER ERROR");
        }
    }
    return;
?>

Parameters in the server to server notification

These parameters are present in the server to server notification:

Parameter Name Description
sourceCode The payment channel used to make the transaction. The values are Net, Adhoc and Phone.
receiptNumber The unique receipt number generated by QuickWeb. This value can be used later to locate this payment in QuickStream Portal.
communityCode Your community code. Provided in communityCode when initialising the payment frame. See View your connection details in QuickStream Portal.
supplierBusinessCode Your supplier business code. Provided in supplierBusinessCode during handoff. See View your connection details in QuickStream Portal.
paymentReference Provided in paymentReference when initialising the payment frame or entered by the payer.
customerReferenceNumber A customer-level reference. Provided in supplierBusinessCode during handoff or entered by the payer.
paymentAmount The payment amount including surcharges.
surchargeAmount The surcharge amount.
cardScheme The card scheme. One of:
  • VISA
  • MASTERCARD
  • AMEX
  • DINERS
  • UNIONPAY
  • JCB
settlementDate The settlement date of the payment. See Transaction settlement.
createdDateTime The date and time of the transaction on the QuickWeb server in Sydney. Format: dd MMM yyyy HH:mm:ss.
responseCode The two digit response code. See Response Codes.
responseDescription The description of the response code. See Response Codes.
summaryCode The one digit summary code. See Response Codes.
successFlag true when the transaction was successful, otherwise false.
Custom fields Any custom parameters that you included in the handoff will be sent back to you.

That is, any parameters prefixed with custom will be included in this notification.

For example:
customTitle,
customPayeeName

If you choose to receive the data as XML, the parameters listed in the table above will instead be built into an XML document. This document will be passed to your server in the body of the request. The request will have a content-type of application/xml.

An example XML response

POST /payments HTTP/1.1
Host: yoursite.com.au
Content-Type: application/xml

<PaymentResponse>
    <sourceCode>Net</sourceCode>
    <receiptNumber>1003548481</receiptNumber>
    <communityCode><YOUR_COMMUNITY_CODE></communityCode>
    <supplierBusinessCode><YOUR_SUPPLIER_CODE></supplierBusinessCode>
    <customerReferenceNumber>CUSTOMER1</customerReferenceNumber>
    <paymentReference>PAYMENT1</paymentReference>
    <paymentAmount>624.00</paymentAmount>
    <surchargeAmount>24.00</surchargeAmount>
    <cardScheme>VISA</cardScheme>
    <settlementDate>20170110</settlementDate>
    <createdDateTime>10 Jan 2017 01:11:31</createdDateTime>
    <responseCode>00</responseCode>
    <responseDescription>Approved or completed successfully</responseDescription>
    <summaryCode>0</summaryCode>
    <successFlag>true</successFlag>
</PaymentResponse>

Cash Applied File

The purpose of the report is to provide you with a detailed list of all the transactions for that day. You can then load the report into your system and use it to help reconcile your bank statements.

Note:

  • It will only include transactions that occur before the banking cut off. Any transactions that occur after the cut off will be included in the next file.
  • QuickStream generates the Cash Applied File at 8pm (Sydney time) each banking day.
  • You can choose to include all the payments in one single file or split the payments into multiple files based on the business group they belong to.
  • You can choose to include only the successful transactions or both the successful and rejected transactions.

File format

The standard CSV format is a “comma separated value” file that we have created for our customers. The file consists of one header row followed by multiple detail rows.

The header row contains the field names.

For example

"Settlement Date","Receipt Number","Merchant Number","Customer Reference Number","Payment Amount"

The detail row contains the details for a particular transaction.

For example

"11-Jun-2012","9742904","MERCHANT1","CUSTOMERA","100.00"

Column Name Description
Settlement Date The settlement date of the payment.

The default date format is DD-MMM-YYYY.
For example: 20-Jun-2012

For refunds, this field contains the settlement date of the refund.
For example, credit card transactions after 6pm Sydney time will settle on the following banking day. See Response codes and settlement for more information.
Receipt Number The unique receipt number generated by QuickStream. This value can be used later to locate the payment in QuickStream.
For refunds, this field contains the new receipt number that was generated at the time of the refund. It is not the receipt number of the original payment.
Supplier Business Code Your supplier business code. You will be notified of this value during the implementation.
For refunds, this is the supplier business code of the original payment.
Reference Number This is an optional column. It will be included if your system provides a referenceNumber parameter to QuickStream during the secure token request.

This value represents a unique payment level reference created by your system. For example: invoice number, credit note number, fine code or transaction reference.

For refunds, this is the reference number of the original payment.
Customer Reference Number This is an optional column. It will be included if your system provides a customerReferenceNumber parameter to QuickStream during the secure token request.

This value represents a unique customer level reference created by your system. For example: customer number, family code, company code, BPAY number.

For refunds, this is the customer reference number of the original payment.
Payment Amount For credit card payments this value is positive. It represents the amount that QuickStream used when it attempted the transaction. It includes any surcharge or GST amount that needed to be paid.

The amount is in dollars and cents. For example, an amount of one thousand and fifteen dollars will be provided as follows:
1015.00

For refunds, this value is negative. It represents the total refund amount. For example, a refund of one thousand and fifteen dollars will be provided as follows:
-1015.00
Surcharge Amount For credit card payments this value is positive. It represents the surcharge amount that QuickStream included in the transaction.

The amount is in dollars and cents. For example, an amount of fifteen dollars will be provided as follows:
15.00

For refunds, this value is negative. It represents the surcharge amount that was included in the refund. For example, an amount of fifteen dollars will be provided as follows:
-15.00
Response Code The two digit response code.
For example: 41

See Response codes and settlement for the list of codes.

For refunds, this field contains the response code for the refund - not the code of the original payment.
Response Description` The description of the response code.
For example: Lost card

See Response codes and settlement for the list of codes and their corresponding description.

For refunds, this field contains the response description for the refund - not the description of the original payment.
Summary Code The one digit summary code.
For example: 1

See Response codes and settlement for the list of summary codes.

For refunds, this field contains the summary code for the refund - not the summary code of the original payment.
Card Scheme (Credit cards only) The type of credit card the customer used to make the payment. QuickStream will return one of the following values:
VISA
MASTERCARD
AMEX
DINERS
JBC
UNIONPAY

For refunds, this is the card type used to make the original payment.
Account Holder Name The account name for bank account payments, or cardholder name that the customer entered.
For example: John Smith

For refunds, this is the card holder name associated with the original payment.
Masked Card Number The credit card number that the customer entered. For security reasons part of this number will be masked.
For example: 45647xxxxxxx004

For refunds, this is the card number associated with the original payment.
BSB Number For bank account payments, this field is populated with the BSB the customer entered on the Payment Details page.

For example: 650-000.
For credit card payments/refunds this field is empty.
Account Number For bank account payments, this field is populated with the account number the customer entered on the Payment Details page.

For example: 987654321.
For credit card payments/refunds this field is empty.
Created Date Time The date and time the transaction was made on the QuickStream server in Sydney.

The default format is DD-MMM-YYYY hh:mm.
For example: 20-Jun-2012 15:04

For refunds, this is the date and time the refund was made on the QuickStream server in Sydney.
Source Product The payment channel used to make the transaction.
For example: NET.
Parent Receipt Number For credit card payments, this field is blank.

For refunds, this field is populated with the receipt number of the original credit card payment.

Sample file

In this example there are two transactions:

  1. A card transaction for 618.00. A sucharge amount of 24.00 was calculated.
  2. A bank account transaction for 50.00.
  3. A card refund transaction for 31.20. A surcharge amount of 1.20 was calculated.
"Settlement Date","Receipt Number","Supplier Business Code","Reference Number","Customer Reference Number","Payment Amount","Surcharge Amount","Response Code","Response Description","Summary Code","Card Scheme","Account Holder Name","Masked Card Number","BSB Number","Account Number","Created Date Time","Source Product","Parent Receipt Number"
"10-Jan-2017","1003548481","MERCHANT1","PAYMENT1","CUSTOMER1","624.00","24.00","00","Approved or completed successfully","0","VISA","John Smith","456471xxxxxxx004","","","10-Jan-2017 01:11","QuickWeb",""
"10-Jan-2017","1003548482","MERCHANT1","PAYMENT2","CUSTOMER2","50.00","0.00","G","WBC Exception processing released successfully","0","UNKNOWN","John Smith","","032-xxx","xxx465","10-Jan-2017 02:56","QuickWeb",""
"10-Jan-2017","1003548483","MERCHANT1","REFUND","CUSTOMER1","-301.20","-1.20","00","Approved or completed successfully","0","VISA","John Smith","456471xxxxxxx004","","","10-Jan-2017 13:46","QuickWeb","1003548480"

Retrieving a Cash Applied File

The file may be retrieved using Westpac iLink, WIBS or available for download in QuickStream Portal.

  • Westpac iLink is a web based service that allows you to securely send files to and receive files.
  • WIBS (Westpac Integrated Banking Services) is a straight through connectivity product, that uses SFTP, HTTP, SOAP or XCOM to deliver files to your server. Westpac iLink is used as the BCP for WIBS.
  • QuickStream Portal is the administrative interface for QuickStream products, such as QuickWeb and QuickConnect.

See WIBS User Guides for more on Westpac iLink or WIBS.

To download a Cash Applied File from QuickStream Portal:

  1. Sign into QuickStream Portal
    • Test: https://quickstream.support.qvalent.com/quickportal
    • Production: https://quickstream.westpac.com.au/quickportal
  2. Click Administration -> Transactions and Reports -> Facility Reports
  3. Your report will appear on this page.
    • Select the download icon to retrieve a Cash Applied File.
    • Use the date filters to find older files.

Download cash applied files from QuickStream Portal.

Manage your security settings

QuickStream Portal is your administration interface for QuickStream. You can manage the following security settings:

Manage your Domain white list

The domain white list holds the allowed domains or URLs for sending server to server notifications. Server to server notifications to URLs that are not in this white list will be rejected, and will not receive a server to server notification.

  1. Sign into QuickStream Portal
    • Test: https://quickstream.support.qvalent.com/quickportal
    • Production: https://quickstream.westpac.com.au/quickportal
  2. Click Administration -> Facility Settings -> Manage Domain White List
  3. Select Add Domain to white list a new domain or specific URL, or select the edit or delete icons to manage existing entries.

You can white list your entire domain, or a specific URL. For example,

  • To receive server to server notifications from any URL on your website, white list yoursite.com.au.
  • To receive server to server notifications at a specific URL on your website, white list yoursite.com.au/payments.

QuickStream Portal allows you to manage your allowed domains.

Manage server to server notifications

Server to server notifications are submitted directly to your system. A HTTP POST with form data or XML sent from QuickStream after a successful credit card payment attempt.

  1. Sign into QuickStream Portal
    • Test: https://quickstream.support.qvalent.com/quickportal
    • Production: https://quickstream.westpac.com.au/quickportal
  2. Click Administration -> Facility Settings -> Manage Server to Server Notification

Manage server to server notifications in QuickStream Portal.

Destination URL

This option can be used for:

You can override this by passing serverReturnUrl in a Secure Token Handoff for the above products except the QuickTerminal and QuickVoice products.

Notification format

Choose HTTPS POST or XML.

Control Description
HTTPS POST The server to server notification will be sent as HTTPS POST form parameters.
XML The server to server notification will be sent as HTTPS POST with XML as the request body.

Automatic retry of failed notifications

Configure the number of times you wish QuickStream to re-send failed notifications. A failed notification is one where a server cannot be reached, or a server responds with a HTTP status code other than 200 OK.

Control Description
If the original attempt fails Choose the time until the system retries the first time.
If this second attempt fails, retry Choose number of times the system should retry after the second attempt.
at intervals of Choose the interval between each subsequent retry.
If all attempts fail, send an email to Enter the email address the system will notify when a server to server notification cannot be sent. You can override this by passing errorEmailToAddress in a Secure Token Handoff.

For example the following setting produces a schedule:

Setting Value
If the original attempt fails Retry 1 minute after the original attempt
If this second attempt fails, retry 3 more times
at intervals of 10 mins
If all attempts fail, send an email to john@yoursite.com.au

This setup will send the following server to server notifications:

  1. Credit card payment made at 12:00 PM
  2. Server to server notification sent at 12:00 PM and failed.
  3. Server to server notification retried at 12:01 PM and failed.
  4. Server to server notification retried at 12:11 PM and failed.
  5. Server to server notification retried at 12:21 PM and failed.
  6. Server to server notification retried at 12:31 PM and failed.
  7. Stop retrying and send an email to john@yoursite.com.au.

Troubleshooting security settings

QuickStream Portal’s Activity Log shows:

  • Unsuccessful secure token request attempts.
  • Unsuccessful server to server notification sending attempts.
  1. Sign into QuickStream Portal
    • Test: https://quickstream.support.qvalent.com/quickportal
    • Production: https://quickstream.westpac.com.au/quickportal
  2. Click Administration -> Activity Log
  3. Select the date you wish to view logs for.

Types of entries you may see for unsuccessful server to server notification attempts are:

  • The URL X is not listed as an allowed end point to post response information to.
  • The URL X is invalid and cannot be used as an end point to post response information to.
  • Received HTTP N instead of HTTP 200 from endpoint X.

QuickStream Portal allows you debug connection problems through the Activity Log.

Testing

The testing process is also known as User Acceptance Testing or UAT. The purpose of UAT is to test the entire solution as thoroughly as possible. The tests are carried out by the relevant participants from your business. We recommend you create a test plan which details the scenarios your verification team need to cover during their testing.

The QuickVoice tests should include:

  • Approved transactions
  • Declined transactions
  • Invalid payment details (eg, reference number too short; invalid credit card number)
  • Duplicate payments

The reporting tests should include:

  • Retrieving your daily payment report (either manually from iLink or automatically using WIBS)
  • Uploading the payment report into your system

The QuickStream Portal tests should include:

  • Creating users
  • Assigning roles to users
  • Searching for payments
  • Refunding payments

To support the testing process a test environment is provided. This environment is also known as the ‘support environment’ or 'support’. It simulates the banking system, allowing you to test credit card payments without affecting any live bank accounts.

The test environment will remain in place after you go live. This will enable you to test any future changes before they are released into production. The test environment is provided on a best-efforts basis. It will occasionally be unavailable due to upgrades to our base products. Please factor this into your testing timelines and raise any concerns you have with your implementation manager.

Test Account Numbers

To help with the testing process we provide a list of account numbers for you to use.

Test Credit Cards

During the testing phase QuickStream will generate a response code based on the credit card number entered. The last 2 digits of the credit card number will map to a particular response code.

  • Any credit card number that ends with a value between 00-89 will result in an approved transaction.
  • Any credit card number that ends with a value between 90-99 will result in a declined transaction.

The table below lists the credit card numbers you can test with and the corresponding response codes are returned.

Visa Logo Visa Test Cards
Last 2 digits of card number Example card number Response code Summary code
00-89 4242424242424242
4111111111111111
4444333322221111
Debit Card: 4041370000456459
08 (Honour with identification) 0 (Transaction Approved)
90 4111111117444490 01 (Refer to card issuer) 1 (Transaction Declined)
91 4111111116444491 04 (Pick-up card) 1 (Transaction Declined)
92 4111111115444492 05 (Do not honour) 1 (Transaction Declined)
93 4111111114444493 91 (Issuer or switch is inoperative) 1 (Transaction Declined)
94 4111111113444494 54 (Expired card) 1 (Transaction Declined)
95 4111111112444495 42 (No universal account) 1 (Transaction Declined)
96 4111111111444496 51 (Not sufficient funds) 1 (Transaction Declined)
97 4111111110444497
Debit Card: 4041370000011197
62 (Restricted card) 1 (Transaction Declined)
98 4111111119444498 43 (Stolen card, pick up) 1 (Transaction Declined)
99 4111111118444499 01 (Refer to card issuer) 1 (Transaction Declined)
Mastercard Logo Mastercard Test Cards
Last 2 digits of card number Example card number Response code Summary code
00-89 5163200000000008
5200000009915957
2224000000031118
Debit Cd. 5188680400000008
08 (Honour with identification) 0 (Transaction Approved)
90 5100000000404390 01 (Refer to card issuer) 1 (Transaction Declined)
91 2229000000002791 04 (Pick-up card) 1 (Transaction Declined)
92 5163200000000792 05 (Do not honour) 1 (Transaction Declined)
93 5500000000101893 91 (Issuer or switch is inoperative) 1 (Transaction Declined)
94 5400000000501994 54 (Expired card) 1 (Transaction Declined)
95 2300000000887995 42 (No universal account) 1 (Transaction Declined)
96 5100000000432896 51 (Not sufficient funds) 1 (Transaction Declined)
97 2710000000011897
Debit Card: 5188683000000097
62 (Restricted card) 1 (Transaction Declined)
98 5200000000022498 43 (Stolen card, pick up) 1 (Transaction Declined)
99 5200000000830999 01 (Refer to card issuer) 1 (Transaction Declined)
Amex Logo Amex Test Cards
Last 2 digits of card number Example card number Response code Summary code
00-89 340000000636513
370000000201048
08 (Honour with identification) 0 (Transaction Approved)
90 340000000075290 01 (Refer to card issuer) 1 (Transaction Declined)
91 370000000024291 04 (Pick-up card) 1 (Transaction Declined)
92 340000000067792 05 (Do not honour) 1 (Transaction Declined)
93 340000000070093 91 (Issuer or switch is inoperative) 1 (Transaction Declined)
94 370000000094294 54 (Expired card) 1 (Transaction Declined)
95 370000000093395 42 (No universal account) 1 (Transaction Declined)
96 340000000089796 51 (Not sufficient funds) 1 (Transaction Declined)
97 370000000092397 62 (Restricted card) 1 (Transaction Declined)
98 370000000064198 43 (Stolen card, pick up) 1 (Transaction Declined)
99 370000000079899 01 (Refer to card issuer) 1 (Transaction Declined)
Diners Logo Diners Test Cards
Last 2 digits of card number Example card number Response code Summary code
00-89 30000000056030
5200000009915957
39000000022686
08 (Honour with identification) 0 (Transaction Approved)
90 39000000000690 01 (Refer to card issuer) 1 (Transaction Declined)
91 38000000008991 04 (Pick-up card) 1 (Transaction Declined)
92 39000000003892 05 (Do not honour) 1 (Transaction Declined)
93 30000000008593 91 (Issuer or switch is inoperative) 1 (Transaction Declined)
94 36000000009694 54 (Expired card) 1 (Transaction Declined)
95 38000000004495 42 (No universal account) 1 (Transaction Declined)
96 39000000004296 51 (Not sufficient funds) 1 (Transaction Declined)
97 30000000006597 62 (Restricted card) 1 (Transaction Declined)
98 36000000003598 43 (Stolen card, pick up) 1 (Transaction Declined)
99 38000000003299 01 (Refer to card issuer) 1 (Transaction Declined)
JCB Logo JCB Test Cards
Example card number Expiry Date CVN Response code Summary code
3530000000000003 10/2025 573 00 (Approved or completed successfully) 0 (Transaction Approved)
3530000000000011 10/2025 573 05 (Do not honour) 1 (Transaction Declined)
UnionPay Logo UnionPay Test Cards
Example card number Expiry Date CVN Response code Summary code
6250947000000014 12/2033 123 08 (Honor with identification) 0 (Transaction Approved)

Sign-off

After you have completed your user acceptance testing you must send a ‘sign off’ email to your Qvalent implementation manager. The email will state that you have successfully tested all aspects of the solution and you are ready for it to be moved into production.

A sample sign off email is included below.

To: Qvalent_implementation_manager

Cc: Westpac_implementation_manager

Subject: QuickVoice sign off

We have successfully completed user acceptance testing. 
Our tests covered all areas of the solution. They included QuickVoice payments, reporting and QuickStream Portal admin tasks.

Our QuickVoice payment tests covered:

-   Approved transactions
-   Declined transactions
-   Invalid payment details
-   Duplicate payments

Our reporting tests covered:

-   Retrieving the daily payment report
-   Uploading the payment report into our system

Our QuickStream Portal admin tests covered:

-   Creating users
-   Assigning roles to users
-   Searching for payments
-   Refunding payments

We are satisfied with the results of these tests and we are ready for the solution to be moved into production.

Regards,
John Smith

Production lodgement

Production lodgement is the final step to complete before going live. It involves:

  • Us configuring our Qvalent/Westpac systems in production
  • You configuring your systems in production
  • You running a set of live, low value tests in production to confirm the solution is ready to go live

Qvalent lodgement tasks

As part of the lodgement process Qvalent will complete the following tasks:

  • Obtain written approval from the security team to allow the solution to be placed into production
  • Install the solution into production
  • Configure connectivity
  • Configure reporting
  • Create your community/business
  • Set up your user roles
  • Create a QuickStream Portal admin user for you to use in production. You will receive the login details for this user via email.
  • Create an iLink admin user for you to use in production. This step is only performed if you have elected to receive files via iLink. You will receive the login details for this user via email.

Your lodgement tasks

To complete the lodgement process you will perform the following tasks:

  • If you will be receiving payment notifications from QuickVoice, update your configuration for the expected QuickVoice IP address so that it uses our production IP address (rather than the support IP address you used for user acceptance testing). The production IP address for QuickVoice is available in the Production URLs and IP addresses section.
  • Test the end to end solution in production using a few small value transactions. This test will take a number of days to complete and will test all of your credit card merchants. The test consists of the following steps:
    1. On day 1, make two small test payments for each credit card merchant
    2. On day 2, check your bank statement. Make sure:
      • the bulk settlement amount is correct
      • the narrative is correct
      • the money has been deposited into the correct bank account
    3. Also on day 2, check your customer’s credit card statement/s. Make sure:
      • The amount is correct
      • The narrative is correct
    4. On day 3, refund all of the payments.
    5. On day 4, check your bank statement. Make sure:
      • The bulk settlement amount is correct
      • The narrative is correct
      • The money has been withdrawn from the correct bank account
    6. Also on day 4, check your customer’s credit card statement/s. Make sure:
      • The amount is correct
      • The narrative is correct

Production URLs and IP addresses

This section lists the URLs and IP addresses you must use in production. They are for the production environment only.

iLink

Description: If you are manually retrieving a Cash Applied File from iLink, use the following URL.

URL: https://ilink.westpac.com.au

QuickStream

Description: This URL will allow you to create users and search for payments.

URL: https://quickstream.westpac.com.au

QuickStream IP adddress

Description: If you are receiving payment notifications from QuickVoice (ie, server-to-server postbacks) use this IP address to validate against.

URL: 192.170.86.153

Go live

Once production lodgement is complete and you are satisfied with the results of your low value tests in production you are ready to go live. The term “go live” represents the date you will make the solution available to your customers.

At this stage of the implementation process there are only a few tasks left to complete. They are:

  • Before the go live date, communicate with your customers to inform them about the new payment process.

  • On the go live date, update the appropriate page (or pages) on your website to make the new solution available to your customers.

After you go live, Qvalent and Westpac will closely monitor the solution. This is known as the “monitoring phase” and lasts for two weeks. During this time, if you have any questions or concerns about the solution you should communicate directly with your Qvalent implementation manager.

Post implementation

Once the two week monitoring phase is over the implementation process is officially complete. Your Qvalent implementation manager will hand the solution over to the Qvalent helpdesk. The helpdesk will be responsible for day to day monitoring of the solution and resolving any issues that occur.

If you have any questions or concerns about the solution at this point contact the helpdesk: QuickStream Technical Support.

Transaction Settlement

Credit card transaction settlement

Westpac credits your account the same day, except on weekends and national public holidays when the settlement is delayed until the next banking day. The amount credited is the total of approved transactions. Any direct debit or 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 (i.e. approved transactions less the merchant service fees), depending on your contract with them. Although Westpac 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.

For reconciliation purposes, all successful transactions through a given acquirer that return the same settlement date will be credited together on the same day.

What are the credit card cut-off times?

The standard cut-off time for credit card payments is 18:00 (Australia/Sydney Time).

When are payments sent to the bank?

Generally, credit card transactions will be processed immediately. The settlement date will depend on the time of processing (whether they were processed before the current day’s cutoff time).

Response codes

These response codes have been presented for your reference and are derived from the message format defined in Australian Standard 2805.2 (1997).

It is highly unlikely that you will receive many of these response codes; as a general rule you should use the provided summary response code to determine whether a transaction is approved or declined. Valid response codes are of a two digit alphanumeric format.

If an unknown response code is returned please contact Westpac with the appropriate transaction details.

Please note that there are no response codes specific to card verification number mismatches. This is because no financial institutions within Australia currently return any such information if declining a transaction for security reasons. Response Codes are generally returned from the customer’s issuing bank.

Credit card transaction response codes

Successful credit card transactions will generally have a response code of 00 - Approved or completed successfully or 08 - Honour with Identification. Other statuses indicate a problem processing the transaction. If you receive a status code starting with ‘Q’ that you do not understand, you should contact your Client Enquiry Manager with the transaction details.

For non approved transaction statuses that do not start with 'Q’ the card holder will likely need to contact their issuing financial institution for more information about the rejected transaction.

When doing so you can recommend they:

  • provide the date and amount of the transaction.
  • request specific information regarding the transaction rejection.
Summary Code Description
0 Approved
1 Declined
2 Error
3 Rejected


Response Code Description Summary Code Soft Decline
00 Approved or completed successfully. More information 0
01 Refer to card issuer. More information 1 Yes
02 Refer to card issuers special conditions 1
03 Invalid merchant. More information 1
04 Pick-up card. More information 1
05 Do not honor. More information 1 Yes
06 Error 1
07 Pick-up card, special condition 1
08 Honor with identification. More information 0
09 Request in progress 1
10 Approved for partial amount 0
11 Approved VIP 0
12 Invalid transaction. More information 1
13 Invalid amount 1
14 Invalid card number (no such number). More information 1
15 No such issuer 1
16 Approved, update Track 3 0
17 Customer cancellation 1
18 Customer dispute 1
19 Re-enter transaction 1 Yes
20 Invalid response 1
21 No action taken 1
22 Suspected malfunction. More information 1 Yes
23 Unacceptable transaction fee 1
24 File update not supported by receiver 1
25 Unable to locate record on file 1
26 Duplicate file update record, old record replaced 1
27 File update field edit error 1
28 File update file locked out 1
29 File update not successful, contact acquirer 1
30 Format error 1
31 Bank not supported by switch 1
32 Completed partially 1
33 Expired card 1
34 Suspected fraud 1
35 Card acceptor contact acquirer 1
36 Restricted card 1
37 Card acceptor call acquirer security 1
38 Allowable PIN tries exceeded 1
39 No credit account 1
40 Request function not supported 1
41 Lost card 1
42 No universal account. More information 1
43 Stolen card, pick up 1
44 No investment account 1
45-50 Reserved for ISO use 1
51 Not sufficient funds 1 Yes
52 No cheque account 1
53 No savings account 1
54 Expired card. More information 1
55 Incorrect PIN 1
56 No card record 1
57 Transaction not permitted to cardholder 1
58 Transaction not permitted to terminal 1
59 Suspected fraud 1
60 Card acceptor contact acquirer 1
61 Exceeds withdrawal amount limits. More information 1 Yes
62 Restricted card 1
63 Security violation 1
64 Original amount incorrect 1
65 Exceeds withdrawal frequency limit 1 Yes
66 Card acceptor call acquirers security department 1
67 Hard capture (requires that card be picked up at ATM) 1
68 Response received too late 1 Yes
69-74 Reserved for ISO use 1
75 Allowable number of PIN tries exceeded 1 Yes
76-89 Reserved for private use 1
90 Cutoff is in process (Switch ending a day’s business and starting the next. The transaction can be sent again in a few minutes). 1 Yes
91 Issuer or switch is inoperative. More information 1 Yes
92 Financial institution or intermediate network facility cannot be found for routing 1 Yes
93 Transaction cannot be completed. Violation of law 1
94 Duplicate transmission 1 Yes
95 Reconcile error 1
96 System malfunction 1 Yes
97 Advises that reconciliation totals have been reset 1
98 MAC error 1
99 Reserved for national use 1
EA response text varies depending on reason for error 2
EG response text varies depending on reason for error 2
EM Error at the Merchant Server level 2
N1 Unknown Error (NZ Only) 1
N2 Bank Declined Transaction (NZ Only) 1
N No Reply from Bank (NZ Only) 1
N4 Expired Card (NZ Only) 1
N5 Insufficient Funds (NZ Only) 1
N6 Error Communicating with Bank (NZ Only) 1
N7 Payment Server System Error (NZ Only) 1
N8 Transaction Type Not Supported (NZ Only) 1
N9 Bank declined transaction (NZ Only) 1
NA Transaction aborted (NZ Only) 1
NC Transaction cancelled (NZ Only) 1
ND Deferred Transaction (NZ Only) 1
NF 3D Secure Authentication Failed (NZ Only) 1
NI Card Security Code Failed (NZ Only) 1
NL Transaction Locked (NZ Only) 1
NN Cardholder is not enrolled in 3D Secure (NZ Only) 1
NP Transaction is Pending (NZ Only) 2
NR Retry Limits Exceeded, Transaction Not Processed (NZ Only) 1
NT Address Verification Failed (NZ Only) 1
NU Card Security Code Failed (NZ Only) 1
NV Address Verification and Card Security Code Failed (NZ Only) 1
Q1 Unknown Buyer 1
Q2 Transaction Pending 2
Q3 Payment Gateway Connection Error. More information 3 Yes
Q4 Payment Gateway Unavailable 3 Yes
Q8 Error verifying 3D Secure enrolment 3
Q9 3D Secure authentication failed 3
QA Invalid parameters 3
QB Order type not currently supported 3
QC Invalid Order Type 3
QD Invalid Payment Amount - Payment amount less than minimum/exceeds maximum allowed limit 1
QE Internal Error 3
QF Transaction Failed 3 Yes
QG Unknown Customer Order Number 3
QH Unknown Customer Username 3
QI Transaction incomplete - contact Westpac to confirm reconciliation 2 Yes
QJ Incorrect Customer Password 3
QK Unknown Customer Merchant 3
QL Business Group not configured for customer 3
QM Payment Instrument not configured for customer 3
QN Configuration Error 1
QO Missing Payment Instrument 3
QP Missing Supplier Account 3
QQ Invalid Credit Card \ Invalid Credit Card Verification Number 1
QR Transaction Retry 2
QS Transaction Successful 0
QT Invalid currency 3
QU Unknown Customer IP Address 3
QV Invalid Capture Order Number specified for Refund, Refund amount exceeds capture amount, or Previous capture was not approved 1
QW Invalid Reference Number 1
QX Network Error has occurred 3 Yes
QY Card Type Not Accepted 1
QZ Zero value transaction 0
RA response text varies depending on reason for rejection 3
RG response text varies depending on reason for rejection 3
RM Rejected at the Merchant Server level 3
No Short for 'No Account’, this response code indicates the QuickVault account used for the transaction was not found. More information. 3

00 - Approved

This indicates that the transaction has been authorised.

What authorisation DOES mean:-

  • The card number is valid
  • The card has not been reported lost or stolen (although it may in fact be lost, stolen or compromised [card details improperly obtained or copied] and the card owner is unaware)
  • There are sufficient funds available to cover the transaction.

What authorisation DOES NOT mean:-

  • An authorisation does NOT confirm that the person providing the card number is the legitimate card holder. The risk remains that the person providing the credit card number has either stolen or improperly obtained the card.

01 - Refer to card issuer

This indicates an error or problem from the card issuer. The problem may be related to the card holder’s account. This response code is often a result of one of the following:-

  • Suspected Fraud
  • Insufficient Funds
  • Stolen Card
  • Expired Card
  • Invalid CVN
  • Any other rule imposed by the card issuer that causes a decline (e.g. daily limit exceeded, minimum monthly payment not made, duplicate transaction suspected, etc).

03 - Invalid merchant

This can indicate a problem with Westpac’s merchant configuration. This can also be returned for AMEX transactions when there is a problem with the setup at American Express. This code can be returned from an issuing bank if they don’t like the acquiring bank. An example of this would be someone trying to pay their speeding fine with an overseas credit card. The overseas issuing bank would return a 03, indicating that they wouldn’t allow the transaction over the internet for an Australian bank.

04 - Pickup Card.

This can mean the card has been reported as lost or stolen. The card holder should contact their issuing bank.

05 - Do not honour

This indicates an error or problem from the card issuer. The problem may be related to the card holder’s account. In general the reason for this response code may be any of the following:-

  • Suspected Fraud
  • Insufficient Funds
  • Stolen Card
  • Expired Card
  • Invalid CVN
  • Any other rule imposed by the card issuer that causes a decline (e.g. daily limit exceeded, minimum monthly payment not made, duplicate transaction suspected, etc).

08 - Honor with identification

This indicates that the transaction has been authorised.

What authorisation DOES mean:-

  • The card number is valid
  • The card has not been reported lost or stolen (although it may in fact be lost, stolen or compromised [card details improperly obtained or copied] and the card owner is unaware)
  • There are sufficient funds available to cover the transaction.

What authorisation DOES NOT mean:-

  • An authorisation does NOT confirm that the person providing the card number is the legitimate card holder. The risk remains that the person providing the credit card number has either stolen or improperly obtained the card.

12 - Invalid transaction

This code is often returned from the issuer when they do not accept the transaction. This can possibly be when a transaction for the same amount and merchant is attempted multiple times quickly for the same card. The card holder should contact their issuing bank.

14 - Invalid card number (no such number)

This code indicates that the card number does not exist. Also returned code if an AMEX card is used, but the merchant is not setup for AMEX cards.

22 - Suspected Malfunction

This code normally indicates that the card number was invalid.

42 - No Universal Account

This error is returned from some issuers when the credit account does not exist at the issuing bank. This situation is similar to the 14 response code.

54 - Expired Card

This error is returned when the credit card has expired. Check that the expiry date is correct, and attempt the transaction again. If the transaction still does not work, check with the card holder to see if they have a new card with a new expiry date.

61 - Exceeds withdrawal amount limits

This error is returned when the card holder does not have enough credit to pay the specified amount. Ask the card holder if they have another card to use for the payment.

91 - Issuer or switch is inoperative

This code is used to indicate that the next party in a credit card transaction timed out and the transaction has been reversed. This may happen between QuickStream and Westpac, or further down the chain. This response may also be returned for pre-authorisation transactions that are manually reversed.

92 - Financial institution or intermediate network facility cannot be found for routing

The card number is incorrect. The first 6 digits of the credit card number indicate which bank issued the card. These are used for routing credit card requests through the credit card network to the issuing bank. This error indicates that there is no bank that corresponds to the first 6 digits of the card number.

QI - Transaction incomplete

This status code indicates that a request message was sent to the QuickStream server but no response was received within the timeout period.

QQ - Invalid Card

The QQ error code indicates that the credit card details (card number, expiry date or CVN) are invalid. This could be because the card number does not meet check digit validation, an invalid expiry date was entered, or an invalid CVN was entered.

QY - Card Type not accepted

The QY error code indicates that the merchant is not enabled for the particular card scheme. This error code is normally returned for American Express and Diners Club cards, or when a UnionPay debit card is used. Only UnionPay credit cards are supported.

Q3 - Payment Gateway Unavailable

The downstream credit card gateway was unavailable. The credit card transaction was not attempted and the transaction record will not exist. When you receive this response code, the transaction will not exist in QuickStream.

No - No Account

The QuickVault account used for the transaction was not found or is not enabled. Please check that the QuickVault account exists and is enabled. You can do this in via QuickGateway or in QuickStream Portal.

Requirements Checklist

Download the Checklist.

The purpose of this section is to help identify your requirements. Use the checklist as follows:

  1. Download the requirements checklist and rename it with your company name.
  2. Complete as much of the checklist as you can before your first meeting with Westpac.
  3. Use the checklist to understand the steps required to implement this product.