QuickWeb

QuickWeb is a Westpac hosted service that enables your website to offer secure online payments.

The key features of the solution are:

  • It integrates with your existing website.
  • The appearance of the QuickWeb pages can be branded to look like your website. This gives the customer the impression the payment is being made from your website.
  • QuickWeb manages the complexities of the payment process, providing you with a summary of the outcome.
  • You can offer your customers credit card payments and bank account payments.

Figure 1 Solution overview

Demo Payment Flow

This page describes the payments QuickWeb solution. Other types of QuickWeb are:

The purpose of this document is to describe the QuickWeb solution and explain how it can integrate with an existing website. High level requirements as well as detailed step-by-step instructions are included in the document to help with the implementation process.

The intended audience for this document is the software development team that will be responsible for integrating QuickWeb with their website.

How does the payment process work?

The following diagram shows the high level sequence of events that take place when a customer makes a payment.

Payment process

The steps for the above diagram are as follows:

  1. The customer visits your website. One of your webpages will include a button (or a link) to QuickWeb. The location of this button will depend on the tasks you want the customer to complete before entering their payment details. For example,

    • You may want to verify the customer’s reference number before showing the button.
    • If your website has a shopping cart, you may want to display the button at the end of the shopping experience.
    • You may not require any verification. In this case you could include a simple link on one of your pages.
  2. Your website will link to QuickWeb after the customer clicks the button. This transition is referred to as the ‘handoff’. The technical details for this process will be discussed further in Link from your website to QuickWeb.

  3. QuickWeb will display the 'Payment Details’ page. Typically this page will allow the customer to enter their payment amount, payment reference and payment details. The content and branding of this page will be discussed further in Branding QuickWeb - Payment Details page.

  4. QuickWeb will display the 'Confirmation’ page. This will allow the customer to review their payment details before QuickWeb proceeds with making a payment. The content and branding of this page will be discussed further in section Branding QuickWeb - Confirmation page.

  5. QuickWeb will make the payment.

  6. QuickWeb will display the 'Receipt’ page. This page includes a button linking back to your website. Note, it is not mandatory for QuickWeb to show the 'Receipt’ page. If you prefer, QuickWeb can redirect back to your website so that you can show the receipt page. This will be discussed further in Link from QuickWeb back to your website.

  7. QuickWeb will return the customer back to your website. This process is known as the 'passback’ and will be discussed further in section Link from QuickWeb back to your website.

  8. Your website will display the appropriate page to the customer.

Implementation process overview

There are a number of tasks involved in implementing a QuickWeb 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/Document Reference
Step 1 Kick-off meeting
Step 2 Branding QuickWeb
Step 3 Linking from your website to QuickWeb
Step 4 Linking from QuickWeb back to your website
Step 5 Receiving payment details
Step 6 Testing
Step 7 Sign off
Step 8 Production lodgement
Step 9 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 QuickWeb

The purpose of this section is to describe the QuickWeb pages that are involved in the payment process and explain how we can tailor their appearance and behaviour to meet your needs. This process is referred to as “branding QuickWeb”.

Branding is the first task we like to complete in the implementation. It allows us to identify your needs early and develop a working set of pages for you to examine in our test environment. This will then allow you to quickly identify any issues and provide us with feedback.

In general it takes 6 weeks to develop a branded set of QuickWeb pages. This will vary depending on your requirements. We also expect there will be 2-3 iterations before the final release.

Defining requirements

There are a number of decisions that need to be made during the branding process. These include:

  • The layout of the page
  • The size and location of images
  • The name and position of buttons and links
  • The size and type of the font/s
  • The data you want your customer to enter in QuickWeb
  • The data you want your customer to enter in your website rather than QuickWeb
  • Identifying additional data you want to pass from your website and have QuickWeb display
  • Whether to display your own receipt page or have QuickWeb show the receipt page

There are three ways you can provide us with your branding information:

1. Provide the URL of your existing website for us to copy

If you would like to have the same look and feel as your existing website, simply provide us with the URL of your website.

We will then use your website as our branding guideline for developing your QuickWeb pages.

2. Provide a branding guide for us to use

If your business has a branding guide or a style guide for website development and you would like us to follow that guide, simply send us a copy of your branding guide.

We will then use this as our branding guideline for developing your QuickWeb pages.

3. Provide us a branded version of the QuickWeb click-through

The QuickWeb click-through is a zip file that contains a simple version of our QuickWeb pages. It shows the flow of the pages, the basic layout of each page and the data we typically request from the customer. Your developers can use this click-through as a base for creating your own branded version of the pages. Once complete, send us the new click-through zip file (including all the required images and CSS).

We will then use this as our branding guideline for developing your QuickWeb pages. Please notify your implementation manager if you have not yet received a copy of the QuickWeb click-through.

Download the QuickWeb click-through

QuickWeb pages

This section describes each of the QuickWeb pages that are involved in the payment process. Sample images have been included to help with the description of each page. These are example images only. As part of the branding process we can change the look and feel of the page, the data we show to the customer and the data we request from the customer.

The basic QuickWeb pages are:

  1. Payment Details page
  2. Confirmation page
  3. Receipt page

Payment Details page

This is the first QuickWeb page in the payment process.

Figure 3 QuickWeb Payment Details page

Figure 3 QuickWeb Payment Details page with bank accounts

Figure 3 QuickWeb Payment Details page

The fields for the “Payment Details” page are described in the following table:

Field Details
Amount The amount the customer needs to pay. This value excludes any surcharge amount.

Note:
- A credit card surcharge amount may be added to this amount after the customer has entered their credit card details.
- If you would like to accept payments in a currency other than Australian dollars please advise.
- If you would prefer the amount to be entered/calculated on your website you can instead pass the value across to QuickWeb during the handoff. QuickWeb will then show the amount as a read only value. For more information about the handoff see Linking from your website to QuickWeb.
Payment Reference The “Payment Reference” is a unique value that identifies the payment. For example, it may represent an invoice number, credit note number, fine code or transaction reference. This value can then be used later to help you reconcile the payment in your backend system.

Note:
- This field is only relevant if a payment level identifier can be provided. If your customers can only provide a customer level identifier you will need to use the “Customer Reference Number” field instead.
- The label for this field may be changed to a name of your choosing. Please advise if a different name would better suit your customers.
- We can validate the value entered by the customer. Typically the number entered would include a check digit for us to verify its validity. Alternatively you can send us a data file that contains the list of accepted values for us to check against. Please advise if you would like validation to occur and specify the validation routine you would like us to apply.
- If you prefer, your system can pass the Payment Reference to QuickWeb during the handoff. This can be done using the paymentReference parameter. QuickWeb will then display the Payment Reference as a read only value. For information about passing the value to QuickWeb see Linking from your website to QuickWeb.
Customer Reference Number The “Customer Reference Number” is a reference that identifies the customer. For example, it may represent a customer number, family code, company code or Bpay number. This value can then be used later to help you reconcile the payment in your backend system.

Note:
- The difference between this field and the “Payment Reference” field is that this field can only allocate the payment to the customer level. For example, it allows you to identify who made the payment but not the specific invoice that was paid.
- The label for this field may be changed to a name of your choosing. Please advise if a different name would better suit your customers.
- We can validate the value entered by the customer. Typically the number entered would include a check digit for us to verify its validity. Alternatively you can send us a data file that contains the list of accepted values for us to check against. Please advise if you would like validation to occur and specify the validation routine you would like us to apply.
- If you prefer, you can pass the Customer Reference Number to QuickWeb from your website. This can be done during the handoff using the customerReferenceNumber parameter. QuickWeb will then display the customer reference number as a read only value. For information about passing the value to QuickWeb see Linking from your website to QuickWeb.
Payment Method This page assumes your customers are allowed to pay via credit card or direct debit. The appearance of the page will change if the customer chooses a different payment method. For example, if “Credit Card” is selected QuickWeb will remove the bank account fields and display credit card fields instead.
If you do not want customers to pay via credit card please advise your implementation manager. We can remove the “Payment Method” field if you are only offering direct debit.
Cardholder Name The name printed on the front of the customer’s credit card
Credit Card Number The number that appears on the front of the customer’s credit card. The value is entered as a continuous string of digits. We recommend that the list of accepted credit cards is also displayed on this page. It is particularly useful if certain credit cards are not accepted (for example Amex or Diners). If you do not include the list here your customer will not be notified about the invalid card type prior to submitting the payment details.
Expiry Date The expiry date printed on the customer’s credit card. The date format must be mm/yy. Separate drop down boxes are provided for the month and year.
Card Verification Number (CVN) The “Card Verification Number” is an additional security number included on the customer’s credit card. Information about the number, where it is located on the card and why it is used appears in a popup window when the customer clicks the “What’s this?” link. An example of this page is included below.
Direct Debit Service Agreement A Direct Debit Request (DDR) Service Agreement is required for bank account payments. It is written by your organisation and outlines the terms and conditions for making direct debit payments.
I accept the Direct Debit Request The customer must agree to the terms and conditions before going to the next page. This is done by ticking the checkbox.
Account Name The customer’s bank account name.
BSB The customer’s BSB (Branch-State-Branch)
Account Number The customer’s bank account number.

Figure 4 What's This? CVN Explanation

Figure 4 What’s This? CVN Explanation

Additional information:

  • If a surcharge is required for certain credit card types please advise your implementation manager. We recommend displaying the surcharge rates for each card type on this page.
  • The “Cancel” button will take the customer back to your website.
  • The “Next” button will take the customer to the “Confirmation” page.

Confirmation page

This page appears after the customer has entered their payment details. It allows the customer to check their details before going ahead with the payment.

Figure 5 Confirmation page

Figure 5 Confirmation page with bank account

Figure 5 Confirmation page

The fields for the “Confirmation” page are described in the following table:

Field Details
Principal Amount The amount the customer entered on the previous page.
Surcharge Amount The surcharge amount calculated by QuickWeb. The calculation is based on the amount entered by the customer and the type of credit card they have used. A checkbox is included at the bottom of the page to ensure the customer is aware of the surcharge. The payment will not be attempted until the customer has ticked this box.
Total Amount The total amount the customer must pay. QuickWeb will calculate this value by adding the Principal Amount and the Surcharge Amount. This is the value that will be charged to the customer’s credit card.
Payment Reference The Payment Reference that the customer entered on the previous page.
Customer Reference Number The Customer Reference Number that the customer entered on the previous page.
Cardholder Name The card holder name that the customer entered on the previous page.
Credit Card Number The credit card number the customer entered on the previous page. For security reasons we do not display the entire credit card number.
Expiry Date The expiry date that the customer entered on the previous page.
Account Name The account name that the customer entered on the previous page.
BSB The BSB the customer entered on the previous page. For security reasons we do not display the whole number.
Account Number The account number the customer entered on the previous page. For security reasons we do not display the whole number.
Verification Code The “Verification Code” is included for security reasons. It is a random computer generated code that can only be read by humans. This prevents hackers from being able to use QuickWeb to automatically validate stolen credit card details. The customer must type the code into the provided field before they are allowed to proceed. Note, this field is not required if: - The “Customer Reference Number” or “Payment Reference” values entered on the “Payment Details” page were validated by QuickWeb. - The “Customer Reference Number” or “Payment Reference” values were provided to QuickWeb in the handoff.

Additional information:

  • The “Back” button will take the customer back to the “Payment Details” page.
  • The “Cancel” button will take the customer back to your website.
  • The “Confirm” button will instruct QuickWeb to attempt the payment. The credit card transaction is conducted in real time. The customer must wait for a response from QuickWeb. At this point the buttons will become inactive and the message “Please wait” will be displayed to the customer. This will prevent the customer from making multiple payment attempts.
  • After the payment is made the receipt page will be displayed. You can choose to have QuickWeb display the receipt page or if you prefer you can display your own receipt page.
  • QuickWeb can also provide your server with payment summary details at this point. See Server to server notification.
Duplicate payments

QuickWeb performs duplicate transaction checks in order to reduce the instances of accidental double payment. See Duplicate payment checking.

Receipt page

The receipt page is shown after the credit card payment is attempted. You can choose to have QuickWeb display the receipt page or if you prefer you can display your own page.

The following image is an example of a QuickWeb receipt page. This page can be branded to match your existing website.

Figure 6 Receipt page

Figure 6 Receipt page with bank account

Figure 6 Receipt page

The data on the receipt page is described in the following table:

Field Details
Status This value indicates whether or not the payment attempt was successful. A value of “Approved” means the payment was successful. A value of “Declined” means the payment attempt was unsuccessful.
Receipt Number A unique transaction ID generated by QuickWeb. This value can be used later to locate the payment in the QuickStream Portal search screens.
Principal Amount The amount the customer entered on the previous page.
Date The date and time that the transaction was made by QuickWeb.
Surcharge Amount The surcharge amount the customer had to pay. It is based on the payment amount entered by the customer and the type of credit card they have used.
Total Amount The total payment amount calculated by QuickWeb. It is calculated by adding the payment amount and surcharge amount. This amount was charged to the customer’s credit card.
Payment Reference The Payment Reference that was entered on the “Payment Details” page.
Customer Reference Number The Customer Reference Number that was entered on the “Payment Details” page.
Cardholder Name The card holder name that the customer entered on the “Payment Details” page.
Credit Card Number The credit card number the customer entered on the “Payment Details” page. For security reasons we do not display the entire credit card number.
Expiry Date The expiry date that the customer entered on the “Payment Details” page.
Account Name The account name the customer entered on the “Payment Details” page.
BSB The BSB the customer entered on the “Payment Details” page. For security reasons we do not display the whole value.
Account Number The account number the customer entered on the “Payment Details” page. For security reasons we do not display the whole value.
Send Receipt Email To This field allows the customer to send a copy of the receipt to the specified email address. The receipt will be included as a PDF attachment. An example PDF receipt is shown below.

Additional information:

  • The “Finish” button will take the customer back to your website. We will use the returnUrl parameter value to do this. You will provide this parameter during the handoff to QuickWeb. See Linking from your website to QuickWebfor details.

  • The “Print” button will display a PDF version of the receipt. The customer can then print the PDF. See example below.

Figure 7 Receipt page

Figure 7 Receipt page with bank account

Figure 7 Receipt page

QuickWeb test poster

The QuickWeb test poster is a webpage that allows you to easily view your QuickWeb pages in our test environment. The page is intended for the test environment only. It will not exist in the live environment. The purpose of the page is to simulate the handoff from your website to QuickWeb. This means you can review the branded QuickWeb pages before you implement your handoff.

The following image is an example of a test poster

Figure 8 Test poster

Figure 8 Test poster

This particular example simulates a secure token handoff (described in Sending parameters via secure token request).

The page is divided into two sections:

  • The “Generate Token” (top) section lists the parameters we expect your server to pass to QuickWeb in the first part of the handoff (ie the secure token request). These parameters are explained in detail in Parameters for secure token request. When the “Generate Token” button is clicked, the webpage will generate a dummy security token and place it in the “Token” field (shown in the bottom section).
  • The “Handoff” (bottom) section lists the parameters we expect the client’s browser to pass to QuickWeb in the second part of the handoff (ie the browser redirect). These parameters are explained in detail in Parameters for redirect.

When the “Submit” button is clicked the first QuickWeb page will appear.

Duplicate payment checking

QuickWeb performs duplicate transaction checks in order to reduce the instances of accidental double payment.

What’s a Duplicate?

A transaction is considered a duplicate if there is a previous transaction that matches all these criteria:

  • has the same credit card number (but not necessarily expiry date) or bank account BSB and account number
  • is for the same merchant
  • is for the same amount
  • is approved or currently processing
  • is not a QuickBatch transaction (but could be QuickVoice, QuickConnect, etc)
  • is for the current settlement date

What is displayed to the card holder?

The card holder is warned of the duplicate and must tick a box in order to continue processing.

Duplicate Payment Check

Can a Merchant Disable the Duplicate Check?

Not directly. However, the duplicate check is not performed if a merchant hosts the (payment details page)[#payment-details-page].

The purpose of this section is to explain in detail how to link your website to QuickWeb. This process is referred to as the ‘handoff’. A high level description of the handoff can be seen in Figure 2 Payment process. Before beginning your implementation of the handoff process you need to decide how you are going to send parameters to QuickWeb. You may choose one of the following options:

  1. Sending parameters via secure token request
  2. Sending parameters via form inputs

Send parameters via secure token request

The secure token request is Westpac’s recommended method for sending parameters. It allows the parameters to be sent directly from your server to QuickWeb. This prevents the customer from being able to tamper with the parameters before they are sent to QuickWeb.

In order to use the secure token request your website must have:

  • a dynamic backend which can send a HTTPS POST directly to the QuickWeb server
  • the ability to make an outbound HTTPS connection to QuickWeb through your proxy and firewall

The parameters for this handoff are listed in Handoff parameters for secure token method.

To help explain how the handoff process works we will use the following example. Your implementation may have different webpages, however the actual handoff steps will be the same.

Figure 9 Secure token request handoff

Figure 9 Secure token request handoff

This example has three pages. The first two pages are an example of what your website may display to the customer before you handoff to QuickWeb. The third page is an example of what QuickWeb may display to the customer after the handoff.

Page 1: The 'Enter Details’ page instructs the customer to enter their amount and payment reference. When the customer clicks the 'Next’ button your website validates the data.

Page 2: The 'Summary’ page displays the amount and payment reference as read only fields. When the customer clicks the 'Next’ button your website will handoff to QuickWeb. The amount and payment reference are passed to QuickWeb during the handoff.

Page 3: The 'Payment Details’ page displays the amount and payment reference as read only fields. Additional fields are also provided for the customer to enter their credit card details.

The following sequence diagram shows how the handoff works using the secure token request. Note:

  • The section highlighted in grey shows the handoff steps. These steps apply for any handoff using the secure token method - not just this particular example. They begin when the customer clicks the last button (or link) on your website.
  • Additional steps have been included before and after the grey box. These steps are specific to this particular example. They are not part of the handoff. They have been included to help demonstrate how the handoff can fit into the overall solution.

Figure 10 Sequence diagram for the handoff using a secure token

Figure 10 Sequence diagram for the handoff using a secure token

The steps for the sequence diagram are as follows:

  1. Enter data & click 'Next’

    • Your website displays the 'Enter Details’ page to the customer (see Page 1 in Figure 9). The customer enters their amount and payment reference then clicks the 'Next’ button.
  2. Post form

    • The customer’s browser posts the form to your server.
  3. Store data

    • Your server validates the amount and payment reference. It then stores the data appropriately so that it can be retrieved later for the handoff.
  4. Return html for summary page

    • Your server produces html for the 'Summary’ page. The summary page includes the amount and payment reference as read only data. This data is not included as hidden fields. Your server sends the html to the customer’s browser.
  5. Click 'Next’

    • The 'Summary’ page is displayed to the customer (see Page 2 in Figure 9). The customer checks to make sure the data is correct then clicks the 'Next’ button. The handoff begins here.
  6. Send request

    • The customer’s browser sends the request to your server to initiate handoff.
  7. Retrieve data

    • Your server builds the parameter list that will be sent to QuickWeb as part of the secure token request.
    • For details see Parameters for secure token request.
    • Note, the parameter list for this example is: username, password, paymentReference and principalAmount.
  8. Request security token

    • Your server makes an outbound HTTPS connection to the QuickWeb server. The parameter list is included in the token request.
  9. Generate security token & store parameters

    • QuickWeb generates a security token and stores your parameter list. A unique token is created for every token request.
    • For example: token=m378813qtvOtylVTvVvpWA7PT14QHltr-AqX2gZ-RFM
    • Note, the security token is valid for 1 hour after it is created and can only be used once.
  10. Return security token

    • QuickWeb returns the security token to your server.
  11. Redirect

    • Your server tells the customer’s browser to redirect to QuickWeb. A list of parameters is included in the redirect. For details see Parameters for redirect.
  12. Request payment page

    • The customer’s browser redirects to QuickWeb. The list of parameters is included in the redirect.
  13. Verify security token & lookup parameters

    • QuickWeb verifies the security token to make sure it has not been tampered with. It then uses the token to lookup the parameters that your server passed to QuickWeb during the security token request (see step 8). The token is then destroyed.
  14. Return html for payment page

    • QuickWeb produces html for the 'Payment Details’ page and sends it to the customer’s browser. The handoff ends here.
  15. Enter payment details

    • The 'Payment Details’ page is displayed to the customer (see Page 3 in Figure 9). The customer enters their credit card details.

Send parameters via form inputs

Form inputs is the second option for sending parameters to QuickWeb. It involves all the parameters being sent directly from the customer’s browser to QuickWeb. It is an easier method to implement, however it does allow the customer to tamper with the parameters before they are sent to QuickWeb. Westpac therefore recommends using the secure token method described in Sending parameters via secure token request instead.

The parameters for the handoff are listed in Handoff parameters for form inputs. The sequence diagram below shows how the handoff (in Figure 9) works using only form inputs. It also explains where the security vulnerability is and describes how the customer may exploit it. Figure 11 Sequence diagram for handoff using form inputs

Figure 11 Sequence diagram for handoff using form inputs

The steps for the above sequence diagram are as follows: 1. Enter data & click 'Next’ - Your website displays the 'Enter Details’ page to the customer (see Page 1 in Figure 9). The customer enters their amount and payment reference then clicks the 'Next’ button.

  1. Post form

    • The customer’s browser posts the form to your server.
  2. Return html for summary page

    • Your server validates the amount and payment reference. It then produces html for the 'Summary’ page. The page:
    • Shows the amount and payment reference as read only data.
    • Includes hidden fields for the amount and payment reference.
    • Includes hidden fields for the mandatory and optional parameters that need to be passed to QuickWeb. For details see Handoff parameters for form inputs.
  3. Click 'Next’

    • The customer views the 'Summary’ page (see Page 2 in Figure 9). They check the data is correct then click the 'Next’ button. The handoff begins here.
  4. Post form

    • The customer’s browser posts the form to QuickWeb.
  5. Return html for payment page

    • QuickWeb produces html for the 'Payment Details’ page. The html is sent to the customer’s browser.
    • The handoff ends here.
  6. Enter payment details

    • The 'Payment Details’ page is displayed to the customer (see Page 3 in Figure 9). The customer enters their credit card details.

The purpose of this section is to explain how the customer can return to your website after QuickWeb has made the payment. This process is referred to as the ‘passback’. A high level description of the passback can be seen in Figure 2 Payment process.

Before implementing the passback you need to decide when you would like the customer to return to your website. You may choose one of the following options:

  1. QuickWeb receipt page linking to your website
  2. QuickWeb redirecting to your website for you to show the receipt page

In this option QuickWeb will display its own receipt page to the customer. The receipt page includes a button that links back to your website. The passback occurs when the customer clicks the button.

The sequence diagram below shows how the customer can return to your website if they use this option.

Figure 12 Sequence diagram for the passback via QuickWeb receipt page

Figure 12 Sequence diagram for the passback via QuickWeb receipt page

The steps for the above sequence diagram are:

  1. Click 'Confirm’

    • QuickWeb displays the 'Confirmation’ page to the customer. The customer reviews the details then clicks the 'Confirm’ button to continue.
  2. Send request

    • The customer’s browser sends the request to QuickWeb.
  3. Make payment

    • QuickWeb makes the payment.
  4. Return html for receipt page

    • QuickWeb builds the html for the receipt page. The page includes a button that links back to your website. QuickWeb will link the button to the returnUrl you provided in the handoff (see details about the handoff). QuickWeb returns the html to the customer’s browser.
  5. Click 'Finish’

    • The customer views QuickWeb’s receipt page. When they have finished reading the page they click the 'Finish’ button. The passback begins here.
  6. Request next page

    • The customer’s browser asks your server for the next page.
  7. Return html for next page

    • Your server returns the html for the next page. The passback ends here.

QuickWeb redirects to your receipt page

In this option QuickWeb will return the customer to your website immediately after the payment is made. Your website will then show a receipt page to the customer. QuickWeb will include a number of parameters in the redirect. They will be included as a list of ampersand delimited parameters.

The parameters that QuickWeb will return are listed in Passback Parameters.

The sequence diagram below shows how the passback works when using this option.

Figure 13 Sequence diagram for the passback using immediate redirect

Figure 13 Sequence diagram for the passback using immediate redirect

The steps for the above sequence diagram are:

  1. Click 'Confirm’

    • QuickWeb shows the 'Confirmation’ page to the customer. The customer reviews the details then clicks the 'Confirm’ button to continue.
  2. Send request

    • The customer’s browser sends the request to QuickWeb to initiate payment.
  3. Make payment

    • QuickWeb makes the payment.
  4. Redirect

    • The passback begins here.
    • QuickWeb builds a list of parameters to include in the redirect. They are included as a list of ampersand delimited parameters. For example: communityCode=ACOMPANY&supplierBusinessCode=ACOMPANY&.... For the full list of parameters see Passback Parameters.
    • QuickWeb instructs the customer’s browser to redirect to the returnUrl you provided in the handoff.
    • Note, our default method for sending this data is via a HTTP get. If you would prefer us to use a HTTP post please advise.
  5. Request receipt page

    • The customer’s browser redirects to your server.
  6. Retrieve parameters

    • Your server retrieves the parameters from the request.
  7. Return html for receipt page

    • Your server builds the receipt page html. The receipt page will include data from the parameter list. Your server returns the receipt page html to the customer’s browser.
    • The passback ends here.

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 IP white list

The IP address white list holds the allowed IP addresses for secure token requests. Requests made from IP addresses that are not in this white list will be rejected, and will not receive a security token.

  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 IP Address White List
  3. Select Add IP Address to white list a new IP address, or select the edit or delete icons to manage existing entries.

QuickStream Portal allows you to manage your allowed IP addresses.

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.

View your connection details

Connection details are required to interact with QuickStream in each environment. These connection details refer to values you must pass for the Secure Token Handoff.

  1. Sign into QuickStream Portal
    • Test: https://quickstream.support.qvalent.com/quickportal
    • Production: https://quickstream.westpac.com.au/quickportal
  2. Click Administration -> Facility Settings -> View Connection Details
  3. Select Secure Token Request to view connection details for the Secure Token Request.

QuickStream Portal allows you to view your connection details and configuration.

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 secure token requests are:

  • A Secure Token Request was received from an IP address that is not in the IP Address White-list for this facility.

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

  • Server to server postback to URL X failed as no username or password is configured for this facility.
  • Server to server postback URL X using HTTP, but should be HTTPS.
  • 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 tests should include:

  • Approved transactions
  • Declined transactions
  • Invalid payment details (eg, reference number too short; invalid credit card number or BSB)
  • 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
  • Resending receipts

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)

Test Bank Accounts

To help test your bank account solution QuickStream will generate response codes based on the BSB values. This will give you the ability to test a broad range of scenarios.

To test bank account payments use the BSBs provided in the table below. Each BSB will return a specific response code and summary code.

  • Rejected transactions (summary code ‘3’) represent errors that are identified early on by QuickStream and Westpac. For example, invalid BSB. These transactions will be stopped on day 1. They will not be passed to the customer’s bank for processing. They will not appear in the night time Payment Report (or morning Payment Report).
  • Declined transactions (summary code '1’) represent errors that are identified by the customer’s bank. These transactions are initially reported as approved in a Payment Report (because they pass Westpac’s high level error checks), but will later be declined in the morning Payment Report.

To test approved transactions use a BSB that is not included in the table below. We recommend using a non Westpac BSB such as 650-000.

BSB Example Account Number Response code Summary Code
032-050 111111 R (WBC Exception Processing Error) 3 (Transaction Rejected)
032-051 111110 1 (Invalid BSB Number) 1 (Transaction Declined)
032-052 111112 2 (Payment stopped) 1 (Transaction Declined)
032-053 111114 3 (Account Closed) 1 (Transaction Declined)
032-054 111116 4 (Customer Deceased) 1 (Transaction Declined)
032-055 111118 5 (No Account/Incorrect Account#) 1 (Transaction Declined)
032-056 222223 6 (Refer to Customer) 1 (Transaction Declined)
032-057 111111 7 (No form PDC held) 1 (Transaction Declined)
032-058 111113 8 (Invalid User ID Number) 1 (Transaction Declined)
032-059 111115 9 (Other) 1 (Transaction Declined)
032-999 999994 G (WBC Exception Processing released successfully) 0 (Transaction Successful)
032-002 123465 G (WBC Exception Processing released successfully) 0 (Transaction Successful)

Test URLs and IP addresses

The following URLs and IP addresses are to be used during testing.

Applications

Name Description URL
QuickStream Portal The administration interface for QuickStream products. https://quickstream.support.qvalent.com/quickportal
iLink Manually retrieve reports for an associated WIBS connection. https://ilink.support.qvalent.com

Services

Name Description URL
Test Poster A webpage to simulate the handoff from your website to QuickStream products. https://quickweb.support.qvalent.com/test/YOURCOMMUNITYCODE
Secure Token Request If you have implemented the handoff using a secure token request use this URL. https://ws.support.qvalent.com/services/quickweb/CommunityTokenRequestServlet
Hand-off Hand-off your customer from your website. https://quickweb.support.qvalent.com/OnlinePaymentServlet3
Server to server notification IP address If you are receiving server to server notifications use this IP address to validate against. 203.39.159.31

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: Sign off

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

Our 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
  • Resending receipts

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.

  • If you are using a secure token request for the handoff we will provide you with a new handoff password to use in production.

Your lodgement tasks

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

  • Change your configuration for the handoff so that your website links to our production instance (rather than the support instance you used for user acceptance testing). See the production URLs.

  • If you have implemented the handoff using the secure token request you will:

    • Change your handoff configuration so that you pass across the new production password. Your Qvalent implementation manager will provide you with this password.
    • Email your Qvalent implementation manager and let them know the IP address of the server that will be making the secure token request.
  • If you will be receiving payment notifications, update your configuration for the expected 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 QuickWeb is included here.

You must also 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 and bank account facilities.

Low value credit card testing

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

Low value bank account testing

The purpose of this test is to ensure your bank account solution is working correctly in production. We recommend using low value amounts (for example $0.20) because these are real payments using real bank accounts.

The low value tests involve a number of steps:

  1. On day 1 do the following:

    • Make 2 customer payments per bank account. For example, if your organisation has 3 bank accounts accepting payments, you should submit a total of 6 payments: 2 for the first bank account, 2 for the second bank account and 2 for the third bank account.
    • Check the night time Payment Report. Make sure it includes all 6 payments with a status of approved.
  2. On day 2 do the following:

    • Check your bank statement(s). Make sure the bulk settlement amount is correct, the narrative is correct and the money has been deposited into the correct bank account.
    • Check the morning Payment Report. Make sure there are no errors.
  3. On day 3 check the morning Payment Report. Make sure there are no errors.

  4. On day 4 do the following:

    • Check the morning Payment Report. Make sure there are no errors.
    • If refunds are in scope, refund all of the payments from step 1.

Production URLs and IP addresses

This section lists the URLs and IP addresses you must use in production.

Applications

Name Description URL
QuickStream Portal The administration interface for QuickStream products. https://quickstream.westpac.com.au/quickportal
iLink Manually retrieve reports for an associated WIBS connection. https://ilink.westpac.com.au

Services

Name Description URL
Secure Token Request If you have implemented the handoff using a secure token request use this URL. https://ws.qvalent.com/services/quickweb/CommunityTokenRequestServlet
Hand-off Hand-off your customer from your website. https://quickweb.westpac.com.au/OnlinePaymentServlet3
Server to server notification IP address If you are receiving server to server notifications use this IP address to validate against. 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.

Security

The QuickStream suite of products complies with Level 1 of the Payment Card Industry Data Security Standard (PCI DSS). The PCI DSS is a multifaceted security standard that includes requirements for

  • security management
  • policies
  • procedures
  • network architecture
  • software design
  • critical protective measures.

For more informaiton, see QuickStream Security Features.

For more information on PCI DSS see PCI SSC Data Security Standards.

To ensure QuickStream maintains this high level of security there are a number of security requirements that must be adhered to. These are listed below.

No client specific dynamic content

QuickStream hosted solution (e.g. QuickWeb) payment pages will not contain any client specified dynamic content. This means that you cannot provide javascript or flash components to be used in these solutions. In particular no site measurement javascript or links will be added to any QuickStream page.

QuickStream pages contain sensitive data such as credit card details. The restrictions mentioned above help prevent attacks such as cross site scripting (XSS).

No remote assets

QuickStream hosted solution (e.g. QuickWeb) payment pages will not fetch content from any third party server. All branding resources such as images and stylesheets will be stored on and served from QuickStream servers.

Cookies are required

QuickStream requires session cookies to be enabled in your customer’s browser. Session cookies are only used to maintain state while accessing QuickStream. No permanent information is stored on the client’s computer once the browser is closed.

Trusting the QuickStream Server

When your server exchanges information with QuickStream over HTTPS it must trust the root level certificate. That is, your server must trust the certificate issued by Verisign - not the certificated issued to Qvalent. The Qvalent certificate will expire and need replacing each year. However the Verisign certificate will have a much longer life (i.e. expire in 2028).

If your server trusts the Qvalent certificate directly your QuickStream implementation will cease to operate when a replacement certificate is installed.

Excessive Failures - IP Blacklisting

To prevent fraud, Qvalent will monitor IP addresses and transactions. If any suspicious behaviour is detected we will blacklist the IP address to prevent it from accessing QuickStream again.

Captcha

QuickStream hosted solutions (e.g. QuickWeb) uses Captcha image protection to prevent hackers from using the website to validate stolen credit card details. The term CAPTCHA stands for “Completely Automated Public Turing test to tell Computers and Humans Apart”. The Captcha program randomly generates a distorted “word” that humans can read but computer programs can’t.

For more information about Captcha see http://www.captcha.net/.

Web Analytics

QuickWeb processes payments using the most up to date security best practices. Analytics sends usage data from hosted payment pages via the web browser to a third party system which cannot be guaranteed as secure and may comprise the sensitive data of your customers.

Due to this, hosted payment page solutions (e.g. QuickWeb and QuickVault Web) do not support incorporating analytics code or tools where data is gathered in the customer’s browser.

Transport Layer Security (TLS)

QuickWeb, QuickConnect and QuickVault require Secure Token Handoff and web browser access made using the encryption standard known as TLSv1.2. QuickWeb, QuickConnect and QuickVault rejects request made using TLSv1, or TLSv1.1.

If you receive an error that resembles the error message below, then the underlying TLS connection was not successful. Your systems need adjustments or upgrades to work properly with this service.

TLSv1 is not strong encryption, please use TLSv1.2 instead

HTTP 429 Too Many Requests

You may receive a HTTP 429 Too Many Requests response code when you have sent too many requests in a given amount of time.

If you send more than 10 simultaneous requests, you may receive a HTTP 429 Too Many Requests response code. You should wait for 20 seconds and resend the request.

Standard Network Ports for HTTP Transmissions

QuickStream sends Payment and Registration Notifications (aka Server to Server Responses) via HTTP on standard ports. These are ports 80 and 443. Other network ports are not available to send Payment and Registration Notifications to your server.

Secure token handoff

This section lists the parameters you may pass to QuickWeb during the handoff. This section is only relevant if you are using the “secure token” method. If you are instead using the “form inputs” method please refer to Handoff parameters for form inputs.

When using the secure token method, parameters are sent to QuickWeb in two separate calls. There are:

Parameters for secure token request

The following table lists the parameters that can be passed to QuickWeb during the secure token request. This step is described in Sending parameters via secure token request step 8.

The parameters must be passed to CommunityTokenRequestServlet. The full URL for the test environment is included in Test URLs and IP addresses. The full URL for the production environment is included in Production URLs and IP addresses.

Mandatory parameters

Parameter Name Description
username Your username. This value will be provided to you.
password Your password. This value will be provided to you.
supplierBusinessCode Your QuickWeb supplier business code. This will be provided to you.
connectionType QUICKWEB
product QUICKWEB

Optional parameters

Parameter Name Description
currencyCode The currency code. This will determine which currency to use when making the payment.

Specify either AUD or NZD.

If this parameter is not provided, QuickWeb will default to AUD.
principalAmount The payment amount. Include this parameter if you want the payment amount to be entered/calculated on your website rather than ours. If you include this parameter QuickWeb will display the “Payment Amount” as a read-only field. The customer will not be able to adjust this value in QuickWeb.

Example:
12.00
paymentReference Include this parameter if you want to pass a unique payment level reference to QuickWeb.

For example: invoice number, credit note number, fine code or transaction reference.

QuickWeb will then display the value in the “Payment Reference” field. The customer will not be able to adjust this value in QuickWeb.
customerReferenceNumber Include this parameter if you want to pass a customer level reference to QuickWeb.

For example: customer number, family code, company code, BPAY number.

QuickWeb will then display the value in the “Customer Reference Number” field. The customer will not be able to adjust this value in QuickWeb.
returnUrl Note: We recommend you use a HTTPS URL for this parameter.
The URL you would like QuickWeb to redirect to after the payment is complete. If you do not provide this parameter QuickWeb will display its own receipt page without a link/ button to your website.

Any parameters included in URL will be provided back to you.

Example: https://www.yoursite.com.au/receipt?Name=John&Age=21

See Linking from QuickWeb back to your website for information on how this parameter is used.
cancelUrl Note: We recommend you use a HTTPS URL for this parameter.
The URL you would like QuickWeb to redirect to if the customer chooses to cancel out of the payment process. If you do not provide this parameter QuickWeb will display is own cancel page.

Any parameters included in the URL will be provided back to you.

Example: https://www.yoursite.com.au/cancelledpayment?Name=John&Age=21
serverReturnUrl Note: You must use a HTTPS URL for this parameter.
The URL you would like QuickWeb to send the server to server notification to.

Example: https://www.yoursite.com.au/processPayment

This parameter is only relevant if you wish to receive the server to server payment notification. See Server to server notification for details.
errorEmailToAddress The email address you would like QuickWeb to send an email to if we cannot deliver the payment notification to your server (e.g. your web site is down).

Example: payments@yoursite.com.au

This parameter is only relevant if you wish to receive the server to server payment notification. See Server to server notification for details.
accountType The type of payment the customer is going to make. This value will influence the appearance of the “Payment Details” page.

Specify either: DIRECT_DEBIT (to restrict to Australian bank account payments), DIRECT_DEBIT_NZ (to restrict to New Zealand bank account payments) or CREDIT_CARD (to restrict to credit card payments). Do not send this parameter if your payer can choose either in your solution.
registerPaymentAccount This parameter is only applicable to your facility when QuickVault is enabled. One of:
  • true
  • false
This will register the account in QuickVault after a successful payment.

Custom parameters

If you would like to provide additional information to QuickWeb you can do this by using a custom parameter. Multiple custom parameters can be passed to QuickWeb.

Parameter Name Description
custom<Custom name>

Example:
customTitle,
customPayeeName
QuickWeb can display this data on the screen and/or pass it back to you in the payment notification.

The parameter name must start with “custom” followed by an uppercase letter. Maximum 100 characters per parameter.

Parameters for redirect

The following table lists the parameters that must be included in the redirect to QuickWeb. This step is described in Figure 10 step 11.

You must pass these parameters to OnlinePaymentServlet3. The full URL for the test environment is included in Test URLs and IP addresses. The full URL for the production environment is included in Production URLs and IP addresses.

Parameter Name Description
communityCode Your QuickWeb community code. This value will be provided to you.
token This is the encrypted token given to you by QuickWeb after you make the secure token request.

See Figure 10 step 10. QuickWeb will use this security token to validate the handoff and lookup parameters.

Sample code for the secure token request

Java

package com.qvalent.demo;
import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.net.InetSocketAddress;
import java.net.Proxy;
import java.net.URL;
import java.net.URLDecoder;
import java.net.URLEncoder;
import java.util.HashMap;
import java.util.Map;
import javax.net.ssl.HttpsURLConnection;

public class TokenRequestExample
{
    // This is the HTTP proxy configuration section.
    // To use basic authentication, other options
    // will have to be specified. This example
    // uses Windows domain-based NTLM authentication.
    // To use a direct connection, set USING_PROXY to false.
    private static final String HTTP_PROXY_URL_STRING =
        "proxy.yourdomain.com.au";
    private static final int HTTP_PROXY_PORT = 8080;
    private static final boolean USING_PROXY = true;
    private static final String TOKEN_REQEST_URL_STRING =
        "https://<environment_url>/CommunityTokenRequestServlet";

    // Here we are initialising a java.net.URL object.
    private static final URL TOKEN_REQUEST_URL =
        new URL( TOKEN_REQEST_URL_STRING );

    public static void main( final String[] args ) throws Exception
    {

        // Add username, password and customer reference number parameters
        // to the request.
        final Map<String, String> params =
            new HashMap<String, String>();
        params.put( "username", "username" );
        params.put( "password", "password" );
        params.put( "customerReferenceNumber", "CUSTOMER1" );
        final String content = getQuery( params );

        // Control block to use either proxy or direct connection.
        final HttpsUrlCOnnection connection;
        if( USING_PROXY )
        {
            final Proxy proxy = new Proxy( Proxy.Type.HTTP,
                                               new InetSocketAddress(
                                                   HTTP_PROXY_URL_STRING,
                                                   HTTP_PROXY_PORT ) );
            connection = (HttpsURLConnection)TOKEN_REQUEST_URL.openConnection( proxy );
        }
        else
        {
            connection = (HttpsURLConnection)TOKEN_REQUEST_URL.openConnection();
        }

        // Token request should be a HTTP POST for enhanced security.
        connection.setRequestMethod( "POST" );

        // The parameters are sent using url form encoding.
        connection.setRequestProperty(
            "Content-Type",
            "application/x-www-form-urlencoded" );

        // Add the content length and language.
        connection.setRequestProperty(
            "Content-Length",
            Integer.toString( content.length() ) );
        connection.setRequestProperty(
            "Content-Language",
            "en-au" );

        // We're going to write out post data and get the response (token),
        // so set both output and input.
        connection.setDoOutput( true );
        connection.setDoInput( true );
        // Set up a writer to write the http post data out.
        final BufferedWriter writer =
           new BufferedWriter(
               new OutputStreamWriter( connection.getOutputStream() ) );
        writer.write( content );
        writer.close(); // This will send the content.

        // Set up a reader to get the token result back from
        // the connection. Build it all up into one string.
        final BufferedReader reader =
           new BufferedReader(
               new InputStreamReader( connection.getInputStream() ) );
        String response = "";
        String buff;
        while( ( buff = reader.readLine() ) != null )
        {
            response += buff;
        }
        reader.close();

        // Print the full response.
        System.out.println( "Response: " + response );

        // Print the token, which will occur after "token="
        // and should be the only response parameter parameter.
        final String token =
            URLDecoder.decode(
                response.substring(
                    response.indexOf( "=" ) + 1 ) ,
                "UTF-8" );
        System.out.println( "Token: " + token );
    }

    // Helper method to construct a URL encoded query from
    // a map of string => string.
    private static String getQuery( final Map<String, String> params )
    throws Exception
    {
        String result = "";
        boolean first = true;
        for( final RequestParameter requestParameter : RequestParameter.values() )
        {
            if( first )
            {
                first = false;
            }
            else
            {
                result += "&";
            }
            result += URLEncoder.encode( requestParameter.getLabel(), "UTF-8" );
            result += "=";
            result += URLEncoder.encode(
                params.get( requestParameter.getLabel() ) == null ?
                "" :
                params.get( requestParameter.getLabel() ),
                "UTF-8" );
        }
        return result;
    }
}

C#

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
using System.Net;
using System.Web;
using System.Collections;
namespace TokenRequestExample
{
    class TokenRequestExample
    {
        static void Main(string[] args)
        {
            byte[] byteArray;
            Stream webpageStream;
            StreamReader webpageReader;
            String webpageContent;
            Hashtable parameters = new Hashtable();
            parameters.Add("username", "username");
            parameters.Add("password", "password");
            parameters.Add("customerReferenceNumber", "CUSTOMER1");
            HttpUtility.UrlEncode("");
            String postData = "";
            Boolean first = true;
            foreach( String key in parameters.Keys )
            {
                if(first)
                {
                    first = false;
                }
                else
                {
                    postData += "&";
                }
                postData += key + "=" + HttpUtility.UrlEncode(parameters[key].ToString());
            }
            String URL = "https://<environment_url>/CommunityTokenRequestServlet";
            byteArray = Encoding.UTF8.GetBytes(postData);
            WebRequest request = WebRequest.Create(URL);
            WebProxy proxy = new WebProxy("proxy.yourdomain.com.au", 8080);
            proxy.UseDefaultCredentials = true;
            proxy.BypassProxyOnLocal = true;
            request.Proxy = proxy;
            request.Method = "POST";
            request.ContentType = "application/x-www-form-urlencoded";
            request.ContentLength = byteArray.Length;
            webpageStream = request.GetRequestStream();
            webpageStream.Write(byteArray, 0, byteArray.Length);
            webpageStream.Close();
            webpageReader = new StreamReader(request.GetResponse().GetResponseStream());
            webpageContent = webpageReader.ReadToEnd();
            Console.WriteLine(webpageContent);
            Console.ReadKey(true);
        }
    }
}

PHP

<?php
    $postFields = array( "username" => "username",
                         "password" => "password",
                         "customerReferenceNumber" => "CUSTOMER1" );
    $postFieldsString = http_build_query( $postFields );
    $curlHandle = curl_init();
    curl_setopt( $curlHandle, CURLOPT_URL, "https://<environment_url>/CommunityTokenRequestServlet" );
    if( array_key_exists( "user", $_POST ) &&
        array_key_exists( "pwd", $_POST ) )
    {
        curl_setopt( $curlHandle, CURLOPT_PROXY, "proxy.yourdomain.com.au:8080" );
        curl_setopt( $curlHandle, CURLOPT_PROXYUSERPWD, $_POST["user"].":".$_POST["pwd"] );
    }
    curl_setopt( $curlHandle, CURLOPT_POST, count( $postFields ) );
    curl_setopt( $curlHandle, CURLOPT_POSTFIELDS, $postFieldsString );
    curl_setopt( $curlHandle, CURLOPT_RETURNTRANSFER, 1 );
    curl_setopt( $curlHandle, CURLOPT_CAINFO, "PCA-3G5.pem" );
    curl_setopt( $curlHandle, CURLINFO_HEADER_OUT, 1 );
    $result = curl_exec( $curlHandle );
?>
<html>
    <head>
    </head>
    <body>
        <p> Header: <?php echo curl_getinfo( $curlHandle, CURLINFO_HEADER_OUT ); ?> </p>
        <?php
            if( curl_errno( $curlHandle ) )
            {
        ?>
                <p> Error: <?php echo curl_error( $curlHandle ); ?> </p>
        <?php
            }
            else
            {
        ?>
                <p> Token: <?php echo $result; ?> </p>
        <?php
            }
        ?>
    </body>
</html>
<?php   
    curl_close( $curlHandle );
?>

Python 3.x

import urllib.request as request
import urllib.parse as parse

USERNAME = ""
PASSWORD = ""
CD_CRN = ""

URL = "https://quickstream.support.qvalent.com/CommunityTokenRequestServlet"

class TokenRequest:

    def __init__(self, url):
        self.url = url
        self.params = {}

    def addParameter(self, key, value):
        self.params[key] = value

    def addParameters(self, dictKeyValues):
        for key in dictKeyValues:
            self.addParameter(key, dictKeyValues[key])

    def performRequest(self):
        details = parse.urlencode(self.params).encode("UTF-8")
        response = request.urlopen(self.url, details)
        return response

    def getToken(self):
        response = self.performRequest().read()
        response = response.decode("UTF-8")
        return response.split("=")[1]

# If you do not have a proxy then delete these
# next four lines.
proxyaddress = 'username:password@proxy.yourdomain.com.au:8080'
proxy = request.ProxyHandler({'https': proxyaddress})
opener = request.build_opener(proxy)
request.install_opener(opener)
#---------------------------------------------

req = TokenRequest(URL)
req.addParameter("username", USERNAME)
req.addParameter("password", PASSWORD)
req.addParameter("cd_crn", CD_CRN)
token = req.getToken()

print(token)

Form inputs handoff

This section lists the parameters you may pass to QuickWeb during the handoff. This section is only relevant if you are using the ‘form inputs’ method. If you are instead using the 'secure token’ method, please refer to Handoff parameters for secure token method.

The following table lists the parameters that can be passed to QuickWeb. This is described in Figure 11 steps 3-5.

The parameters must be passed to OnlinePaymentServlet3. The full URL for the test environment is included in Test URLs and IP addresses. The full URL for the production environment is included in Production URLs and IP addresses.

Mandatory parameters

Parameter Name Description
communityCode Your QuickWeb community code. This value will be provided to you.
supplierBusinessCode Your QuickWeb supplier business code. This will be provided to you.

Optional parameters

Parameter Name Description
currencyCode The currency code. This will determine which currency to use when making the payment.

Specify either AUD or NZD.

If this parameter is not provided, QuickWeb will default to AUD.
paymentReference Include this parameter if you want to pass a unique payment level reference to QuickWeb.

For example: invoice number, credit note number, fine code or transaction reference.

QuickWeb will then display the value in the 'Payment Reference’ field. The customer will not be able to adjust this value in QuickWeb.
customerReferenceNumber Include this parameter if you want to pass a customer level reference to QuickWeb.

For example: customer number, family code, company code, Bpay number.

QuickWeb will then display the value in the 'Customer Reference Number’ field. The customer will not be able to adjust this value in QuickWeb.
returnUrl The URL you would like QuickWeb to redirect to after the payment is complete. If you do not provide this parameter QuickWeb will display its own receipt page without a link / button to your website.

Any parameters included in URL will be provided back to you.

Example: http://www.yoursite.com.au/receipt?Name=John&Age=21

Note, there are two ways we can return the customer to your website
  1. QuickWeb can redirect straight away, allowing you to display your own receipt page.
  2. QuickWeb can display its own receipt page and include a link/button for the customer to click on to link back to your website.
    cancelUrl The URL you would like QuickWeb to redirect to if the customer choses to cancel out of the payment process. If you do not provide this parameter QuickWeb will display is own cancel page.

    Any parameters included in the URL will be provided back to you.

    Example: http://www.yoursite.com.au/cancelledpayment?Name=John&Age=21
    accountType The type of payment the customer is going to make. This value will influence the appearance of the 'Payment Details’ page.

    Specify either: DIRECT_DEBIT (to restrict to Australian bank account payments), DIRECT_DEBIT_NZ (to restrict to New Zealand bank account payments) or CREDIT_CARD (to restrict to credit card payments). Do not send this parameter if your payer can choose either in your solution.

    Custom parameters

    If you would like to provide additional information to QuickWeb you can do this by using a custom parameter. Multiple custom parameters can be passed to QuickWeb.

    Parameter Name Description
    custom<Custom name>

    Example:
    customTitle,
    customPayeeName
    QuickWeb can display this data on the screen and/or pass it back to you in the payment notification.

    The parameter name must start with 'custom’ followed by an uppercase letter.

    Passback parameters

    The following table lists the parameters that QuickWeb will return in the passback. The data can then be presented to your customers on your receipt page. For more details about the passback see Link from QuickWeb back to your website.

    All parameters are mandatory unless stated otherwise.

    Parameter Name Description
    communityCode Your QuickWeb community code. This value will be provided to you.

    Note, this is the same value that you will pass to QuickWeb during the handoff.
    supplierBusinessCode Your QuickWeb supplier business code. This will be provided to you.

    Note, this is the same value that you will pass to QuickWeb during the handoff.
    paymentAmount The amount that QuickWeb 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:
    1015.00
    surchargeAmount The surcharge amount that was included in the transaction.

    The amount is in dollars and cents.

    For example:
    15.00
    receiptNumber The unique receipt number generated by QuickWeb. This value can be used later to locate this payment in QuickStream Portal.
    paymentReference This is an optional parameter. It will be included if the customer provided a unique payment level reference.

    For example: invoice number, credit note number, fine code or transaction reference.

    This value was either:
    1. entered in the ‘Payment Reference’ field on the QuickWeb 'Payment Details’ page, or
    2. entered on your website then passed to QuickWeb during the handoff using the paymentReference parameter.
    customerReferenceNumber This is an optional parameter. It will be included if the customer provided a customer reference.

    For example: customer number, family code, company code, Bpay number.

    This value was either:
    1. entered in the 'Customer Reference Number’ field on the QuickWeb 'Payment Details’ page, or
    2. entered on your website then passed to QuickWeb during the handoff using the customerReferenceNumber parameter.
    responseCode The two digit response code.

    For example: 41

    See Transaction Response Codes for more information.
    responseDescription The description of the response code.

    For example: Lost card

    See Transaction Response Codes for more information.
    summaryCode The one digit summary code.

    For example: 1

    See Transaction Response Codes for more information.
    createdDateTime The date and time of the transaction on the QuickWeb server in Sydney.

    Format: DD MMM YYYY hh:mm

    For example: 20 Jun 2012 15:04
    settlementDate The settlement date of the payment. Transactions after 6pm Sydney time will settle on the following banking day. For more information see Transaction Settlement.

    Format: YYYYMMDD

    For example: 20120620
    cardHolderName The card holder name that the customer entered.

    For example: John Smith
    maskedCardNumber The credit card number that the customer entered.

    For security reasons part of this number will be masked.

    For example: 456471xxxxxxx004
    cardScheme The type of credit card the customer used to make the payment. QuickWeb will return one of the following values:
    • VISA
    • MASTERCARD
    • AMEX
    • DINERS
    • UNIONPAY
    • JCB
    expiryDateMonth The month that the customer entered into the expiry date field. This value will be 2 digits long.

    For example: 03
    expiryDateYear The year that the customer entered into the expiry date field. This value will be 4 digits long.

    For example: 2013
    accountName The account name that the customer entered on the 'Payment Details’ page.

    For example: John Smith
    accountNumber The account number that the customer entered on the 'Payment Details’ page. For security reasons part of this number will be masked.

    For example: xxxxxx789
    bsb The BSB that the customer entered on the 'Payment Details’ page. For security reasons part of this number will be masked.

    For example: xxx-000
    hmac A HMAC_SHA256 signed string of the parameters in the passback. Use this to validate that the parameters in the passback were not tampered. See Validating the HMAC.
    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 the passback.

    For example:
    customTitle,
    customPayeeName

    For example

    GET /thankyou?
    communityCode=<YOUR_COMMUNITY_CODE>&amp;
    supplierBusinessCode=<YOUR_SUPPLIER_CODE>&amp;
    surchargeAmount=24.00&amp;
    paymentAmount=624.00&amp;
    paymentReference=INVOICE1&amp;
    customerReferenceNumber=CUSTOMER1&amp;
    receiptNumber=1003548481&amp;
    responseCode=00&amp;
    responseDescription=Approved+or+completed+successfully&amp;
    summaryCode=0&amp;
    createdDateTime=10+Jan+2017+01%3A11%3A31&amp;
    settlementDate=20170110&amp;
    cardholderName=John Smith&amp;
    maskedCardNumber=456471...004&amp;
    cardScheme=VISA&amp;
    expiryDateMonth=04&amp;
    expiryDateYear=2020&amp;
    hmac=13c747bb128c69cca9697c7d63ad5161ccce3c658951ea85ffe239e0a908fa16 HTTP/1.1
    Host: yoursite.com.au
    

    Validating the HMAC

    The HMAC is included in the parameters returned in the passback. Use this to validate the parameters in the passback were not tampered.

    The parameters in the passback are signed using the HMAC_SHA256 algorithm. Your secure token request password is used as the secret in the HMAC_SHA256 calculation. Find the password by viewing your connection details in QuickStream Portal.

    To validate the hmac parameter:

    1. Remove hmac from the list of parameters returned and order the parameters ASCIIbetically by name.
    2. URL encode each parameter with UTF-8 character encoding.
    3. Join the parameter names and values with = and each pair with & (as per a query string).
    4. Generate the HMAC from this string using secure token request password.
    5. Hexadecimal encode the resulting string.
    6. Compare the HMAC string you generated to the hmac parameter in the passback.

    HMAC validation example

    This example illustrates a simple validation of the hmac parameter in the passback.

    Step 1: Get the list of parameters returned in the passback.

    Parameter Name Parameter Value
    communityCode COMCODE
    supplierBusinessCode SUPP
    principalAmount 10.00
    customParam this is a custom param with special characters &
    hmac dce3bc3945ca4d33151fb4c6a69971d86c35556cc2becafb3cb451f080af3d49

    Step 2: Remove hmac and order the parameters ASCIIbetically by name.

    Parameter Name Parameter Value
    communityCode COMCODE
    customParam this is a custom param with special characters &
    principalAmount 10.00
    supplierBusinessCode SUPP

    Step 3: URL encode each parameter with UTF-8 character encoding

    Ensure the encoded characters are lowercase and not uppercase (for example, %3A not %3a.)

    Parameter Name Parameter Value
    communityCode COMCODE
    customParam this+is+a+custom+param+with+special+characters+%26
    principalAmount 10.00
    supplierBusinessCode SUPP

    Step 4: Join the parameter names and values with = and each pair with &.

    communityCode=COMCODE&customParam=this+is+a+custom+param+with+special+characters+%26&principalAmount=10.00&supplierBusinessCode=SUPP

    Step 5: Generate the HMAC from this string using secure token password.

    public static String hash( final String password, final String queryString )
    {
        final Mac mac = Mac.getInstance( "HmacSHA256" );
        mac.init( new SecretKeySpec( password.getBytes( "UTF-8" ), "HmacSHA256" ) );
        return Hex.encodeHexString( mac.doFinal( queryString.getBytes() ) );
    }
    

    Finally, compare the HMAC string you generated to the hmac parameter in the passback. If the strings do not match, there has likely been tampering of the parameters and their values and should not be considered accurate.

    Soft descriptors for Aggregators

    Soft-descriptors are informational fields that Aggregators must collect for each transaction. Other merchants cannot use these fields. These merchant descriptor fields allow some control over the cardholder narrative for each transaction. The Secure Token Request includes new fields to provide these soft-descriptors.

    Read more about Soft descriptors for Aggregators.

    Secure Token Request Fields

    These fields are sent in a Secure Token Request.

    Parameter Name Length Required Description (for a Payment)
    merchantName 22 Yes This field is only relevant for credit card payments for Aggregators.
    Must be in the format AggregatorName*SubMerchantName.
    For example:
    • AggregatorName is Jane's Transactions, abbreviated to JAT.
    • SubMerchantName name is Jill's Bikes.
    • The value of this field may be JAT*JillsBikes.
    AggregatorName can be either in full or abbreviated and must be 3 characters.
    Westpac may suggest a three character aggregator name during your implementation.
    merchantStreetAddress 48 Yes This field is only relevant for credit card payments for Aggregators.
    The street address of the sub-merchant’s trading address.
    It is a scheme requirement to populate the street address as part of the payment. Westpac does not hold the street address information for sub-merchants and it will not appear on the cardholder’s or merchant’s statement.
    Must contain the street address lines only:
    • Include the city or suburb in Merchant Location.
    • Include the state in Merchant State.
    • Include the country in Merchant Country.
    • Include the post code in Merchant Post Code.
    merchantLocation 13 Yes This field is only relevant for credit card payments for Aggregators.
    The city or suburb of the sub-merchant’s trading address.
    merchantState 3 Yes This field is only relevant for credit card payments for Aggregators.
    The state of the sub-merchant’s trading address. One of:
    • NSW
    • ACT
    • VIC
    • QLD
    • NT
    • SA
    • WA
    • TAS
    Merchant Country 2 Yes This field is only relevant for credit card payments for Aggregators.
    Must be set to AU.
    The sub-merchant must be registered in Australia and have a presence and process payments within Australia.
    merchantPostCode 4 Yes This field is only relevant for credit card payments for Aggregators.
    The postal code of the sub-merchant’s trading address.
    subMerchantId 15 Yes This field is only relevant for credit card payments for Aggregators.
    A unique identifier for your sub-merchant. The aggregator allocates the sub-merchant identifier. Westpac does not allocate this value.

    Passback and Payment Notification

    No additional fields are provided in the passback to your website or payment notification to your server.

    3D Secure Card Payments

    Use QuickWeb to accept card payments verified using 3D Secure. 3D Secure is an additional layer of authentication that protects you from liability for fraudulent card payments. Unlike regular card payments, 3D Secure requires cardholders to complete an additional verification step with the card-issuer.

    3D Secure is also known as Mastercard SecureCode and Verified by Visa.

    See 3D Secure Card Payments for QuickWeb for more.

    Payment procedure

    Credit card transactions

    The payment procedure for credit card payments is simple. Card payments occur in real-time: the transaction is made between Westpac and the payer’s issuing bank. The issuing bank responds to Westpac with a response code to report the success or failure of the credit card transaction.

    Bank account transactions

    The payment procedure for bank accounts is more complex than the payment procedure for credit cards. It will take 3 banking days to fully process a bank account payment. During this time you will receive a number of Payment Reports from QuickStream. A Payment Report (also known as a Cash Applied File or CAF) is a file that contains information about the payments submitted by your customers. QuickStream will generate a night time Payment Report and a morning Payment Report.

    The night time Payment Report is generated at 8pm Monday-Friday. It lists the valid bank account payments that have been submitted by your customers that day. A ‘valid’ payment is a payment that has passed the high level error checks performed by QuickStream and Westpac. Payments that fail these checks will be deemed invalid and won’t be included in the Payment Report. Note:

    • The report only includes payments that are submitted before the cut off time. For bank account payments this is 4pm Sydney time each banking day. Transactions that occur after this time will be included in the next file.
    • You can choose to have bank account payments and credit card payments in the same file or separate files.
    • 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.

    The morning Payment Report is generated at 6am Monday-Friday. It lists the bank account payments that have been declined overnight by the customers’ banks. The Payment Report can include any payment request from the previous 3 banking days.

    The sequence diagram below explains the payment procedure in more detail:

    • Steps 1-3 show what happens immediately after a customer submits their payment details.

    • Steps 4-12 show the scheduled events that relate to that payment.

    Sequence diagram explaining the bank account payment procedure

    The steps for the sequence diagram are:

    Day 1 (steps 1-6)

    • Step 1: Click “Confirm”

      • QuickWeb shows the “Confirmation” page to the customer (see the Confirmation Page for more information). The customer reviews the details then clicks the “Confirm” button to continue.
    • Step 3: Send Request

      • The customer"s browser sends the request to QuickWeb.
    • Step 3: Save payment details

      • QuickWeb performs a basic error check on the payment then saves the payment details. Errors such as invalid BSB or invalid account number may be identified at this point.
    • Step 4: Send Payment File
      • At 4pm QuickStream creates a payment file and sends it to Westpac’s payment processor. The file contains a list of all the payments customers have submitted since the previous banking day.
    • Step 5: Send Exception/Disbursement File
      • Westpac performs high level error checking on each of the payments in the file. An Exception Disbursement file (also known as a Direct Entry Exception Disbursement file or DEEDS file) is then created and sent back to QuickStream. This file lists all the payments and categorises each one as either valid or invalid. Behind the scenes Westpac will also send a debit request to each customer’s bank.
    • Step 6: Send Payment Report
      • At 8pm QuickStream creates a Payment Report (also known as a Cash Applied File or CAF). The report contains information about:
      • valid bank account payments
      • successful credit card payments
      • For information about the Payment Report format see Cash Applied File.

    Day 2 (steps 7-8)

    • Step 7: Send Returns File
      • At 6am Westpac will create a Returns file (also known as a Direct Entry Return Processing System file or DERPS file) and will send it to QuickStream. The Returns file contains all the overnight error notifications sent in by other banks. These errors are low level errors that can only be identified by the customer’s bank.
      • The Returns file can relate to any payment request from the previous 3 banking days, not just the payment request made in step 1. For example, the Returns file created on Thursday may contain errors related to payments made on Monday, Tuesday or Wednesday.
    • Step 8: Send Payment Report
      • QuickStream creates a Payment Report and sends it to your system. The report contains declined bank account payments only. It is based on the Returns file received in the previous step. All the errors in the Returns file will be copied into the Payment Report. If the Returns file is empty the Payment Report will also be empty. For information about the Payment Report see Cash Applied File.

    Day 3 (steps 9-10)

    • Step 9: Send Returns File

      • At 6am Westpac creates a Returns file and sends it to QuickStream. This step is identical to step 7.
    • Step 10: Send Payment Report

      • QuickStream creates a Payment Report and sends it to your system. This step is identical to step 8.

    Day 4 (steps 11-12)

    • Step 11: Send Returns File

      • At 6am Westpac creates a Returns file and sends it to QuickStream. This step is identical to step 7.
    • Step 12: Send Payment Report

      • QuickStream creates a Payment Report and sends it to your system. This step is identical to step 8.

    Processing is complete. Any payment that was included in the night time Payment Report on day 1 (see step 6) and not included in the morning Payment Report on day 2, day 3 or day 4 (see steps 8, 10 & 12) can now be considered successful.

    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).

    Bank account transaction settlement

    Direct debit transactions work differently from credit card transactions in that there is no immediate response from your customer’s bank to indicate whether the transaction worked. Instead, the transaction is assumed to have worked unless it is later declined by the customer’s bank. The customer’s bank can decline the transaction for up to 3 banking days after the transaction was processed.

    Your Direct Debit facility configuration will affect how successful and failed transactions are represented on your statement. For example, your account may be credited with the total amount of all direct debit transactions processed in one settlement day. Your account may also be debited with the amount of declined (or “returned”) direct debit transactions. If no transactions are returned, you will not receive a debit that day.

    What are the Direct Debit cut-off times?

    The standard cut-off time for Direct Debit payments is 16:00 (Australia/Sydney Time).

    When are payments sent to the bank?

    Generally, Direct Debit transactions performed before 16:00 (Australia/Sydney) will be submitted to the bank for processing at 16:00.

    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.

    Bank account transaction response codes

    (aka Direct Entry Transaction Response Codes)

    In all cases where the response code requires the account holder to contact their bank, it will help if they can provide a date and amount of the failed attempted transaction and specifically ask the bank why they returned that status for the attempted transaction. Otherwise the issuing bank staff may just check the available funds in the account.

    Successful Direct Entry transactions will generally have a response code of G - WBC Exception Processing released successfully.

    Summary Code Description
    0 Approved
    1 Declined
    2 Processing
    3 Rejected


    Code Description Summary Code Soft Decline
    Zero Zero 0
    No Account No Account Registered 1
    Duplicate Duplicate Transaction 1
    New New 2
    1 Invalid BSB Number 1
    2 Payment stopped. More information 1
    3 Account Closed. More information 1
    4 Customer Deceased 1
    5 No Account/Incorrect Account#. More information 1
    6 Refer to Customer. More information 1 Yes
    7 No form PDC held 1
    8 Invalid User ID Number 1
    9 Other. More information 1 Yes
    Success Approved or completed successfully 0
    R WBC Exception Processing Error - see description 3
    G WBC Exception Processing released successfully. More information 0
    C WBC Exception Processing - Cancelled 3
    D WBC Exception Processing - Recalled 3
    No Short for ‘No Account’, this response code indicates the QuickVault account used for the transaction was not found. More information. 3

    2 - Payment Stopped

    The account holder has requested that their bank stop any direct debit transactions. Contact the customer to determine an alternate payment mechanism, or if they wish to stop their service.

    3 - Account Closed

    The account holder has closed their account. Contact your customer to ask for new account details.

    5 - No Account/Incorrect Account

    Contact your customer to determine if the BSB and account number you have is correct. It may be useful for them to fax you the first page of their bank account statement so that you can check you have the correct BSB and account number.

    6 - Refer to Customer

    Contact your customer to determine if they have sufficient funds in their account, if the BSB and account number you have is correct, and if their account allows direct debit transactions.

    9 - Other

    The banks use this response code as they see fit. If you receive this response code for a customer and you have never had a successful debit for that customer, first check the BSB and account number. This could indicate one of the following:

    • Account does not allow Direct Debit
    • Incorrect Account Number
    • Insufficient Funds
    • Suspected Fraud
    • Any other rule imposed by the account holder’s bank that causes a decline (e.g. daily limit exceeded, duplicate transaction suspected, etc)

    G - WBC Exception Processing released successfully

    The transaction is being processed by Westpac. If the debit is from another bank, Westpac has sent the transaction to that bank. When a direct entry transaction is successful, it remains in this response code. When a transaction is declined and returned, the response will be set to a different response code.

    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.