SecureFrame Integration Guide

Page 1 of 35
© SecurePay Pty Ltd
Document Control
This is a controlled document

Description SecureFrame Integration Guide

Creation Date 02/10/2013 Created By SecurePay

Current Version 1.13 Date Updated 31/01/2025

Changes 1.13 Please note Merchant Initiated Transaction

functionality (including the Standing
Instruction field) is not available yet. We will
advise you of the date and provide detailed
instructions ahead of the changes.
1.12 • Updated the following sections
o 4.2.4 – clarified that Account
Verification will only be triggered
during “Store Only” if the card
provided is Visa or Mastercard
o A.3.2 – removed the paragraphs
relating to Account Verification
since it’s already covered in 4.2.4

1.11 • Added optional field Customer Code

• Updated for Merchant Initiated
Transactions following Mastercard and
Visa scheme mandates. The below
changes are only applicable to selected
acquiring banks (NAB and fiserv FDMSA).
o Added optional fields Standing
Instruction Type
• Added new fields in the response –
Standing Instruction Type, Standing
Instruction ID

1.10 • Updated Section 1.3 to add fiserv FDMSA

as supporting institutions

Page 2 of 35
© SecurePay Pty Ltd
Table of Contents
Introduction .................................................................................................................................................. 4
About this guide ....................................................................................................................................... 4
Intended Audience .................................................................................................................................. 4
System Overview .................................................................................................................................... 4
Feedback .................................................................................................................................................. 5
Additional Payment Choices.................................................................................................................. 5
Technical Overview for Payment Choice – PayPal ........................................................................... 6
Integration .................................................................................................................................................... 8
1. General Information ...................................................................................................................... 8
2. Transaction URL’s ......................................................................................................................... 9
3. Mandatory Fields ........................................................................................................................... 9
4. Transaction Options .................................................................................................................... 12
5. Receiving Results Parameters .................................................................................................. 17
6. Testing........................................................................................................................................... 18
Appendices ................................................................................................................................................ 19
Appendix A: Accepted Input Fields ................................................................................................... 19
A.1. Mandatory Fields....................................................................................................................... 20
A.2. Transaction Fields..................................................................................................................... 22
A.3. Card Storage Fields .................................................................................................................. 23
A.4. FraudGuard Fields .................................................................................................................... 25
A.5. Surcharge Fields ....................................................................................................................... 26
A.6. Transaction Flow Fields ........................................................................................................... 27
A.7. Look and Feel Fields ................................................................................................................ 30
Appendix B: Results Fields .................................................................................................................. 32
B.1. Standard Result Fields ............................................................................................................. 32
B.2. Preauthorisations ...................................................................................................................... 33
B.3. FraudGuard Result Fields........................................................................................................ 34
B.4. Card Storage Result Fields ..................................................................................................... 34
B.5. Surcharge Result Fields ........................................................................................................... 35

Page 3 of 35
© SecurePay Pty Ltd
Introduction

About this guide

This guide provides technical information about integrating and configuring SecurePay’s
SecureFrame within your shopping cart of application.
SecureFrame offers a secure and flexible hosted service that helps you meet your PCI DSS
obligations.

Intended Audience
This document is intended for developers, integrating SecurePay’s SecureFrame with their
applications or shopping cart.
It is recommended that someone with web site, HTML and application programming experience
reads this guide and implements SecureFrame.

System Overview
SecurePay’s SecureFrame provides merchants with the ability to process card payments in a
secure environment.
SecurePay partners with the following major banks and financial institutions in the provision of
the SecurePay Payment Gateway:
• ANZ
• American Express
• BankWest
• Commonwealth Bank
• Diners Club
• National Australia Bank
• St George (including Bank of SA)
• Westpac
• fiserv FDMSA
SecureFrame supports card transactions only.
It is a fully hosted service and comes with a variety of options to help you integrate such as:
• Full page templates
• Call-back of results to your application
• Redirect options for receipt page
• FraudGuard
• Surcharging
• Card storage and tokenisation

Page 4 of 35
© SecurePay Pty Ltd
Feedback
Continuous improvement is one of SecurePay's core values. We welcome any feedback you
have on our integration guides to help us improve any future changes to our products.
If you wish to leave feedback, please email us at support@[Link].

Additional Payment Choices

SecureFrame also provides the following payment options. Please contact the Payment Choice
provider for details on how to sign-up.
• PayPal

If you wish to accept PayPal transactions via SecureFrame please follow the steps below:
1. Inform the SecurePay Support team of your intention to use PayPal.
2. If you don’t have a Business PayPal Account, establish an account with PayPal.
3. Login to the SecurePay Merchant Login.
4. Navigate to the following location:
• Click on [Manage] dropdown list and click on [PayPal Settings].
• Click on [Change Settings] button.
5. Click on the [Retrieve API Credentials] link on the page.
• Note: A popup window will appear. Please ensure you have popups enabled in
your web browser.
6. Login to PayPal using your credentials.
7. Copy and paste the credentials into [Step 8] and close the popup window.
8. Add the following PayPal credentials obtained from [Step 7] to the Merchant Login
PayPal settings page:
• API Username
• API Password
• API Signature
9. Add the company logo URL (Optional). The URL must be publicly accessible and must
be securely hosted (HTTPS).
10. Save changes.

Note: Once PayPal has been enabled and configured successfully you can view PayPal
transactions processed via Direct Post through the SecurePay Merchant Login.

Page 5 of 35
© SecurePay Pty Ltd
Technical Overview for Payment Choice – PayPal
PayPal uses a secure page, hosted by PayPal and presented to your customer as part of the
payment authorisation. To enable PayPal transactions through SecureFrame (from your end),
the website must pass through the tender type of “PAYPAL” within the “card_types”
SecureFrame input field.
1. Generate a Fingerprint
A Fingerprint is generated in your website code by a HMAC SHA-256 hash comprised of
your SecurePay Merchant ID, transaction password, transaction type, transaction
reference, the payment amount, and a timestamp. This value is then presented on your
payment form as a hidden field. Use your transaction password as the secret key. SHA-1
support is being decommissioned over the coming months and once support is fully
dropped, only HMAC SHA-256 will be used. In the transition period, to use HMAC SHA-
256, provide “isSHA256=” in the callback URL. It can be appended at the end. Do not
provide a value, just leave blank as is. Once support for SHA-1 is stopped, you will not
need to provide the parameter in the callback URL but can continue to send as it will not
be used by SecureFrame. See examples for callback URL in section A.6.5.

For HMAC SHA-256 fingerprint

<input type="hidden" name="callback_url"

value="[Link]

2. Website submits transaction to SecureFrame

Your website submits the transaction details to SecureFrame, which will interpret the
optional “card_types” input to determine if “PAYPAL” is included.

If included, SecureFrame will render the alternative payment page, which allows the
customer to select either to pay with any of the accepted card types, or to select PayPal.

If the customer selects PayPal and the “Continue” button, they will be presented with the
PayPal login/registration page.

3. Customer’s PayPal account

Your customer logs into or registers their PayPal account, confirms shipping and billing
details (as required), and selects the payment tender. Your customer will then submit the
payment for processing.

4. Redirect to SecureFrame result Page

Upon completion of the transaction, the customer is redirected to the SecureFrame result
page.

5. Customer returned to the online store

The customer selects to “Continue” from the SecureFrame result page and using the
“return_url” or “return_url_target” they will be redirected to the URL specified. This also

Page 6 of 35
© SecurePay Pty Ltd
 passes the result parameters back to your system. Your system should check the
Fingerprint, update your database and display the receipt to the Customer.

Note: to ensure that the result is passed back to your system successfully, it is
recommended that you use the “callback_url” field. This passes the results back to your
system as soon as the transaction is complete, rather than waiting for the customer to
select the “Continue” button. This prevents missing transactions caused by customers
closing the web browser without selecting to “Continue”.

SHA-1 support is being decommissioned over the coming months and once support is
fully dropped, only HMAC SHA-256 will be used. In the transition period, to use HMAC
SHA-256, provide “isSHA256=” in the callback URL. It can be appended at the end. Do
not provide a value, just leave blank as is. Once support for SHA-1 is stopped, you will
not need to provide the parameter in the callback URL but can continue to send as it will
not be used by SecureFrame. See examples for callback URL in section A.6.5.

Important Information: Processing a PayPal transaction

Only “txn_type=0” is supported to process a PayPal transaction. Any other

transaction type, used in conjunction with “card_types=PAYPAL” will return the
error: “Unsupported Transaction Type for PayPal”

SecurePay FraudGuard cannot be used in conjunction with PayPal payments.

Page 7 of 35
© SecurePay Pty Ltd
Integration
1. General Information

1.1. TLS Support

Clients integrating with SecurePay must be configured to use TLS v1.2 or TLS v1.3. TLS
versions 1.1 and below, as well as all SSL versions, are not supported.
In addition, insecure ciphers such as Triple-DES (3DES) and RC4 are not accepted.
Merchants should configure their webservers to follow a similar TLS profile, only
permitting secure cipher suites and TLS v1.2 and above.
More information and additional detail on a secure TLS configuration can be found at the
following publications:
o Australian Government's Australian Signals Directorate (ASD) TLS and HTTPS
configuration guidelines
o New Zealand Government Communications Security Bureau (NZ GCSB) Information
Security Manual
o NIST Guidelines for the Selection, Configuration, and Use of Transport Layer
Security

1.2. Case Sensitivity

All field “name” and “value” attributes should be treated as case sensitive.

1.3. Sending Data

SecureFrame accepts POST or GET data from your application to initiate a transaction,
however POST is the preferred action type.
When using an HTML form, the following “form” tags are used to encapsulate
SecureFrame inputs:
<form method="post" action="[Link]
…
</form>
All INPUT fields must occur between the “form” tags for correct submission of
information to the SecureFrame Live and Test servers.

You may also add the “name” attribute or any other form functionality that you require.

1.4. Acceptable Form Input Tags

Any HTML form tags may be used to submit information to SecureFrame.
This document deals predominantly with the “input” tag, however, you may use any form
tag to create the necessary name/value data pairs that form the information interpreted
by the service.

Page 8 of 35
© SecurePay Pty Ltd
 Most data are normally passed as “hidden” type input fields. Some fields that may be
entered by your customer is typically passed as “text” type input fields.
Form inputs follow the structure:
<input type=”field_type” name=”field_name” value=”field_value”>

2. Transaction URL’s
Listed below are the live and test URLs for performing several functions
2.1. Test URL
[Link]
2.2. Live URL
[Link]

3. Mandatory Fields
3.1. Bill Name
The Bill Name defines the flow of the transaction process.

“bill_name” must be set to “transact”

Example: Set the bill name for the default transaction process:
<input type="hidden" name="bill_name" value="transact">

3.2. Merchant ID
The Merchant ID field, “merchant_id”, is mandatory. It is the SecurePay account used to
process payments.

SecurePay Customer Support will supply your Merchant ID when your account is
activated. The Merchant ID will be of the format “ABC0001”, where ABC00 is your
unique account code.
Example: Setting the SecurePay Merchant ID:
<input type="hidden" name="merchant_id" value="ABC0001">

3.3. Transaction Type

The “txn_type” defines the payment process. It allows switch of the payment type, as
well as addition of optional services such as FraudGuard. It also forms part of the
Fingerprint.
3.3.1. Payment
Payments are real-time, immediately authorised card transactions. Transaction
information is submitted by your customer via SecureFrame to your SecurePay
account for immediate processing.
Example: Form fields required to make a card payment

Page 9 of 35
© SecurePay Pty Ltd
 <input type="hidden" name="merchant_id" value="ABC0001">
<input type="hidden" name="primary_ref" value="Test Reference">
<input type="hidden" name="txn_type" value="0">
<input type="hidden" name="amount" value="100">
<input type="hidden" name="fp_timestamp" value="20220228022758">
<input type="hidden" name="fingerprint"
value="33de8f9454a62513838ce534309c76ff8ac2c925bfda0364663d83625449789
9">

3.3.2. Pre-Authorisation

A pre-authorisation is a transaction that reserves funds on a card account. The

Merchant can then complete the transaction later and receive the funds. If the pre-
authorisation is never completed, it expires, usually after five days. After this, the
reserved funds are again available to the card holder.

Pre-authorisations are often used by hotels to reserve funds at booking time and
then completed when the guest checks out.
To pre-authorise an amount, submit all the fields exactly as they were for the
PAYMENT transaction type above and set:
<input type="hidden" name="txn_type" value="1">

3.4. Transaction Amount

The "amount" mandatory field is the amount that will be transacted through your
SecurePay account. By default, the currency is AUD (Australian Dollars).

It must be passed in the base unit of the currency. For Australian Dollars this is cents.
For example, $1.00 AUD would be passed as “100”. 100 Yen would be passed as “100”.

Example: Setting the transaction amount

Scenario: A customer chooses items from your shopping cart totalling AUD$53.20.

<input type="hidden" name="amount" value="5320">

3.5. Transaction Reference

The "primary_ref" mandatory field is used to tag orders with an identifier meaningful to
you. This may be your invoice number or could be a unique tracking number produced
as part of your own web site.

The Payment Reference is available to the Result URL and emails, and appears as the
Transaction Reference in the SecurePay Merchant Log In.

It is recommended that the Transaction Reference is unique to aid in reconciliation.

Example: Defining a Transaction Reference

Scenario: Your Company wants to include its invoice numbers with every payment.

<input type="hidden" name="primary_ref" value="642193">

Page 10 of 35
© SecurePay Pty Ltd
 3.6. GMT Timestamp

You must pass a valid Greenwich Mean Time (GMT) timestamp in the field "fp_timestamp"
(also known as UTC).

The timestamp used to generate the fingerprint must exactly match the one sent
with the associated transaction.

It must be of the format "YYYYMMDDHHMMSS" where:

• YYYY is the current year
• MM is the current two digit month 01 – 12
• DD is the current two digit day 01 – 31
• HH is the current two digit hour in 24-hour format 01 – 24
• MM is the current two digit minute 00 – 59
• SS is the current two digit second 00 – 59

Example: Setting the GMT timestamp

Scenario: Your system has generated a Fingerprint. It is currently [Link] on

20/06/2011 in Sydney (+10 hours from GMT). The time in GMT is [Link] on the
same day.

<input type="hidden" name="fp_timestamp" value="20110620123505">

3.7. Fingerprint

The Fingerprint is a protected record of the amount to be paid. It must be generated and
then included as an input field to SecureFrame. It prevents a customer modifying the
transaction details when submitting their card information.

SHA-1 support is being decommissioned over the coming months and once support is
fully dropped, only HMAC SHA-256 will be used. In the transition period, to use HMAC
SHA-256, provide “isSHA256=” in the callback URL. It can be appended at the end. Do
not provide a value, just leave blank as is. Once support for SHA-1 is stopped, you will
not need to provide the parameter in the callback URL but can continue to send as it will
not be used by SecureFrame. See examples for callback URL in section A.6.5.

The Fingerprint is a HMAC SHA-256 hash of the below mandatory fields, plus the
SecurePay Transaction Password in this order with a pipe separator “|”:
• “merchant_id”
• Transaction Password (supplied by SecurePay Support)
• “txn_type”
• “primary_ref”
• “amount”
• “fp_timestamp”

Example: Setting the fingerprint

Fields joined with a | separator:

ABC0001|txnpassword|0|Test Reference|100|20220228022758

Page 11 of 35
© SecurePay Pty Ltd
 HMAC SHA-256 of the above string using your transaction password as the secret key
(e.g. txnpassword):
33de8f9454a62513838ce534309c76ff8ac2c925bfda0364663d836254497899

<input type="hidden" name="fingerprint"

value="33de8f9454a62513838ce534309c76ff8ac2c925bfda0364663d836254497899">

4. Transaction Options
4.1. Receipt Page Redirect

Display of the receipt page and button options on the hosted receipt page can be
optionally controlled.

By default, SecureFrame will display the receipt page to the customer.

To redirect to your own receipt page, set “display_receipt=no”.

If SecureFrame displays the receipt (default), you can control the button on the receipt
page via the following optional parameters:
• return_url – the fully qualified URL to embed in the button link. The system will
append result parameters to this link by default.
• return_url_text – the text of the button
• return_url_target – the target of the button. This can be one of “self”, “new”,
“parent” or “top”. “parent” is useful when using the iFrame template to take the
browser back to full screen.

Example: Set the button to say “Continue...” and take the browser out of the iFrame
when clicked.
<input type="hidden" name="return_url" value="[Link]
<input type="hidden" name="return_url_text" value="Continue...">
<input type="hidden" name="return_url_target" value="parent">

By default, the return_url is used when a Cancel button is clicked by the card holder.
This url can be explicitly set by using the “cancel_url” parameter.

4.2. Card Storage

The card number used in the transaction may be optionally stored for subsequent batch
or XML transaction triggering.

By setting the field "store=yes”, the card will be stored in SecurePay’s Payor system
using the “primary_ref” as the Payor ID by default.

Please note standing_instruction_type field is not available yet. We will advise

you of the date and provide detailed instructions ahead of the changes. For Visa
and Mastercard cards and selected acquiring banks (NAB and fiserv FDMSA), the
standing instruction may be optionally provided using standing_instruction_type field. If
this is passed, the card scheme will send a unique identifier called Standing Instruction
ID that links to the payment history between the customer and merchant. SecurePay

Page 12 of 35
© SecurePay Pty Ltd
 will store the SIID against the payor or token and will pass the value in subsequent
transaction.

4.2.1. Payor

This is the default card storage method.

With Payor storage, you define the Payor ID to store with the card. Customer Code
can also be defined which can be a unique (within you organisation) identifier of
your customer. Cards, Payor ID’s and Customer Codes can be edited via the
Merchant Login. For any payor created with a Customer Code, it should always be
passed along with the payor ID in all types of requests.
You may also set “store_type=payor” to use this storage type.
You may optionally pass in an alternative value for the stored Payor ID to override
the use of primary_ref.
Set “payor” to your required value.

Example: Set card storage with type Payor and my own Payor ID
<input type="hidden" name="primary_ref” value=”123456”>
<input type="hidden" name="store” value=”yes”>
<input type="hidden" name="store_type” value=”payor”>
<input type="hidden" name="payor” value=”MyCustomer”>
<input type=”hidden” name=”customer_code” value=”MyCustomerCode”>
<input type=”hidden” name=”standing_instruction_type”” value=”1”>

4.2.2. Token

A Token is a string that represents a stored card number. If the card number
changes, so does the token, therefore card numbers and tokens cannot be edited,
they may only be added or deleted. However, a Customer Code can also be
assigned for each token and can be edited through Merchant Portal.
Tokens can be used in 3rd party systems to represent card numbers.
If a card is passed to the system for storage several times, the same token is
always returned.
To have SecurePay generate a token for a card or return an existing token for a
pre-stored card set “store_type=token”.
SecureFrame will return the token in the result parameters.
Example: Set card storage with type Token

<input type="hidden" name="primary_ref” value=”123456”>

<input type="hidden" name="store” value=”yes”>
<input type="hidden" name="store_type” value=”TOKEN”>
<input type="hidden" name="customer_code” value=”MyCustomerCode”>
<input type="hidden" name="standing_instruction_type” value=”1”>

Page 13 of 35
© SecurePay Pty Ltd
 4.2.3. Stored Transaction Reference

When triggering a payment from a stored card of Payor or Token via batch or API,
the Transaction Reference defaults to the Payor ID (or Token). This can be
overridden by setting a specific Transaction Reference at the time of storage.
Set the “payor_ref” field to store your desired Transaction Reference against the
stored card.

This is particularly useful; for tokens, as the token does not necessarily represent
your customer. Customer Code can also be used in conjunction with the
Transaction Reference.

Example: Set card storage with type Token and your own Transaction Reference

<input type="hidden" name="primary_ref” value=”123456”>

<input type="hidden" name="store” value=”yes”>
<input type="hidden" name="store_type” value=”TOKEN”>
<input type="hidden" name="payor_ref” value=”123456”>
<input type="hidden" name="customer_code” value=”MyCustomerCode”>
<input type="hidden" name="standing_instruction_type” value=”1”>

In this example, the Payment Reference ID and the stored Transaction Reference
for future triggering are the same.

4.2.4. Store Only

When you choose to store a customer’s card details in SecurePay’s card storage
system when a SecureFrame transaction is processed, you can optionally choose
to store their card details without charging their card. This is known as the Store
Only method. Ensure that you have customer’s agreement before storing their
card.
When you use Store Only, the amount included is ignored and is not stored against
the customer’s details
Please note the account verification and standing_instruction_type
functionality is not available yet. We will advise you of the date and provide
detailed instructions ahead of the changes. For Visa and Mastercard cards and
selected acquiring banks (NAB and fiserv FDMSA).

• An Account Verification will be initiated to verify the card with the bank
before it gets stored. This verification step is a mandatory requirement from
schemes which will help reduce customer complaints and improve approval
rates.
• The standing instruction may be optionally provided using
standing_instruction_type field. If this is passed, the card scheme will send
a unique identifier called Standing Instruction ID that links to the payment
history between the customer and merchant. SecurePay will store the SIID

Page 14 of 35
© SecurePay Pty Ltd
 against the payor or token and will pass the value in subsequent
transaction.
To use Store Only, additional to the standard mandatory fields you must:
• Pass through the txn_type value of 8 in your requests. This value is defined
further in section A.1.3.
TYPICAL USE <input type=”HIDDEN” name=”txn_type” value=”8”>
• Set display_receipt to false – See section A.6.1. for more details.
• Set confirmation to false – See section A.6.1 for more details.
• Set store_type to “payor”.
• Set store to “yes”.
• Pass through payor to set the value for the payor id.
• Pass through customer code to set the value for the customer code
(optional).
• Set applicable standing instruction type (Optional for Visa and Mastercard
and if acquiring with NAB or fiserv FDMSA).
• Generate a fingerprint and pass this through as the fingerprint value in your
requests. This is a protected record of the transaction details and prevents a
customer modifying the details when submitting their card information. Your
system will need to create a HMAC SHA-256 hash of the following fields in
order, separated by “|”. These fields are different to the standard fingerprint
fields described in section A.1.7.
merchant_id|TransactionPassword|txn_type|store_type|payor|fp_timestamp
Example:

ABC0001|txnpassword|8|payor|PayorTest|20220228022758
TYPICAL USE <input type=”HIDDEN” name=”fingerprint”
value=”882df414d8583ec99aea9f89177d0cb529d98b0cad400e3d58c9653a
95105a2d”>
When you use Store Only, only the following result fields are returned:
o Strestext
o Fingerprint
o Strescode
o Payor
o Customer Code, if provided
o Summarycode
o Standing instruction type (applicable to NAB and fiserv FDMSA)
o Standing instruction ID (applicable to NAB and fiserv FDMSA)

SHA-1 support is being decommissioned over the coming months and once
support is fully dropped, only HMAC SHA-256 will be used. In the transition
period, to use HMAC SHA-256, provide “isSHA256=” in the callback URL. It
can be appended at the end. Do not provide a value, just leave blank as is.
Once support for SHA-1 is stopped, you will not need to provide the
parameter in the callback URL but can continue to send as it will not be
used by SecureFrame. See examples for callback URL in section A.6.5.

Page 15 of 35
© SecurePay Pty Ltd
 4.3. Currency

If your bank supports multicurrency, you may optionally set the currency of the
transaction to one other than AUD.

Set the field “currency” to any ISO three letter currency value.

Example: Set the currency to USD

<input type="hidden" name="currency" value="USD">

4.4. Surcharging

Surcharging may be applied across all card types (Visa, MasterCard, etc.), or set
individually per card type.

Surcharging can be either or both:

• A percentage rate of the invoice total (e.g., 1%)
• A flat fee (e.g., $2.00). The fee is added on top of any rate.

To activate surcharging set “surcharge=yes”. This will not apply any surcharging unless
rates and/or fees have been set. It will turn on optional result parameters.

To set a surcharge rate of 1%, set “surcharge_rate=1”.

Example: Set a surcharge rate of 1% for all cards
<input type="hidden" name="surcharge" value="yes">
<input type="hidden" name="surcharge_rate" value="1">

Individual rates and fees may be also set per card.

Example: Set a surcharge rate of 1% for Amex only
<input type="hidden" name="surcharge" value="yes">
<input type="hidden" name="surcharge_rate_a" value="1">

4.5. Template

There are several options to control how the hosted pages are displayed to your
customers. This is controlled by the optional “template” parameter. Responsive is the
recommended template.
Set “template=responsive” to use the responsive version. This version displays only the
input fields, confirmation text and form buttons. It also will perform well on multi form
devices and has friendly CSS tagging.
Set “template=default” to use the full screen payment option. If the template parameter
is omitted, this is the default.
Tip: use the Return URL text and target options to control the payment flow from within
the iFrame.

Example: Set the template to responsive

<input type="hidden" name="template" value="responsive">

Page 16 of 35
© SecurePay Pty Ltd
 4.6. Look and Feel

Several options can be passed to the system to change the look and feel. These include
the header logo, the page title and the primary reference name, among others.

Example: Set the logo, title and primary reference values

<input type="hidden" name="page_header_image"
value="[Link]
<input type="hidden" name="title" value="Payment Page">
<input type="hidden" name="primary_ref_name" value="Order Number">

For more look and feel options, please see section A.7.

4.7. PayPal

SecureFrame contains the ability to pass customers to PayPal to complete their

transaction through their PayPal account. If your SecurePay account is enabled to use
this feature and your website passes through “PAYPAL” under “card_types”, the
SecureFrame payment page will render differently to normal, enabling a tender selection
between the accepted card types and PayPal.

Without passing through “PAYPAL” under “card_types” the normal SecureFrame credit
card payment page will be rendered, which will accept the “card_types” passed through.

To enquire about enabling this feature on your SecurePay account please speak to
SecurePay’s Payment Gateway Advisors on 1300 786 756 (option 2).

Example: Set the accepted tenders to Visa, MasterCard and PayPal

<input type="hidden" name="card_types" value="VISA|MASTERCARD|PAYPAL">

4.8. FraudGuard

FraudGuard is an optional service offered by SecurePay. It must be activated on your

SecurePay account before it can be enabled by setting the “txn_type” field.

See the Appendices for more details.

Please contact SecurePay Sales for pricing and more information.

5. Receiving Results Parameters

The system will send back to your URL’s a predefined set of result parameters.
Some parameters will only be returned if an option is activated, such as “store”.
The system will POST result parameters the first time it calls your server but will send result
parameters using the GET method based on RFC 2616 standards after being redirected.
Result parameters are available to you via two methods:

Page 17 of 35
© SecurePay Pty Ltd
 • Return URL – When you specify a result URL, result parameters are appended to the
URL. This occurs for both receipt page redirect and for the return button on the hosted
receipt page.
• Call-back URL – SecureFrame contacts your system in the background and sends result
parameters
In addition, you can configure a unique cancel URL which overrides the return_url when the
Cancel button is clicked on the page.
All result parameters are listed in the Appendices.

6. Testing

As you build your system you can test functionality, when necessary, by submitting parameters
to the test URL. You can generate a fingerprint and then complete the transaction by using the
card details listed below.
6.1. Test Card Number, Type and Expiry

Use the following information when testing transactions:

Card Number : 4444333322221111
Card Type : VISA
Card CCV : 123
Card Expiry : 08 / 24 (or any date greater than today)

6.2. Simulating Approved and Declined Transactions

You can simulate approved and declined transactions by submitting alternative payment
amounts.

If the payment amount ends in 00, 08, 11 or 16, the transaction will be approved once
card details are submitted. All other options will cause a declined transaction.

Payment amounts to simulate approved transactions:

$1.00 (100)
$1.08 (108)
$105.00 (10500)
$105.08 (10508)
(or any total ending in 00, 08)

Payment amounts to simulate declined transactions:

$1.51 (151)
$1.05 (105)
$105.51 (10551)
$105.05 (10505)
(or any totals not ending in 00, 08)

Note that when using the live URL for payments, the bank determines the transaction
result, independent of the payment amount

Page 18 of 35
© SecurePay Pty Ltd
Appendices
Appendix A: Accepted Input Fields
Mandatory Transaction Surcharging Flow

bill_name currency surcharge display_receipt

merchant_id display_cardholder_n surcharge_rate return_url
ame
txn_type surcharge_fee return_url_text
amount surcharge_rate_v return_url_target
Card Storage
primary_ref surcharge_fee_v callback_url
Store
fp_timestamp surcharge_rate_m cancel_url
fingerprint surcharge_fee_m cancel_url_text
Card Storage
surcharge_rate_a cancel_url_target
(Optional)
surcharge_fee_a confirmation
store_type
surcharge_rate_d
payor
surcharge_fee_d Look and Feel
payor_ref
surcharge_rate_j template
customer_code
surcharge_fee_j primary_ref_name
standing_instruction_t
ype page_header_image
page_footer_image
FraudGuard page_title
(Optional)
card_types
billing_country
page_style_url
delivery_country
email_address

Page 19 of 35
© SecurePay Pty Ltd
A.1. Mandatory Fields
A.1.1. bill_name

Class Mandatory

Format Fixed value “transact”

Description Defines the transaction process.

Typical Use <input type="hidden" name="bill_name" value="transact">

A.1.2. merchant_id

Class Mandatory

Format Alpha-numeric, length 7

A unique identifier for the Merchant within the Payment Gateway. This
Merchant identifier value is an alphanumeric string allocated to you by
Description
SecurePay. This merchant identifier value is not the same as the merchant
number provided by your bank.

Typical Use <input type="hidden" name="merchant_id" value="ABC0001">

A.1.3. txn_type

Class Mandatory

Format Numeric

Used to determine the processing type for an individual transaction. May be

one of the following:

A card payment/purchase transaction.

0 PAYMENT Note: This is the only accepted type for PayPal
payments.

Used to pre-authorise an amount on a card. The

result parameters include the “preauthid” which
1 PREAUTH
must be stored and used when completing the
Description pre-authorisation

PAYMENT with A card payment/purchase transaction with the

2
FRAUDGUARD optional FraudGuard service

PREAUTH with A card preauthorisation transaction with the

3
FRAUDGUARD optional FraudGuard service

This will store the card details without taking a

8 STORE ONLY payment or preauthorisation. See section 4.2.4.
for more details

Page 20 of 35
© SecurePay Pty Ltd
 Typical Use <input type="hidden" name="txn_type" value="0">

A.1.4. amount

Class Mandatory

Format Numeric, integer, from 1 to 99999999

The total amount of the purchase transaction. This value must be a positive
integer in the base unit of the currency, such as cents for AUD. Please be
Description
careful to correctly specify the amount as the system has no method of
determining whether an amount has been correctly specified.

Typical Use <input type="hidden" name="amount" value="10795">

A.1.5. primary_ref

Class Mandatory

Format String, min length 1, max length 60

A string that identifies the transaction. This string is stored by SecurePay as

Description the Transaction Reference. This field is typically a shopping cart id or invoice
number and is used to match the SecurePay transaction to your application.

Typical Use <input type="hidden" name="primary_ref" value="My Reference">

A.1.6. fp_timestamp

Class Mandatory

Format String, format "YYYYMMDDHHMMSS" in GMT (UTC).

The GMT time used for Fingerprint generation. This value must be the same
submitted to generate a fingerprint as submitted with the transaction.
Description
SecurePay validates the time to within one hour of current time. The time
component must be in 24-hour time format.

Typical Use <input type="hidden" name="fp_timestamp" value="20220228005104">

A.1.7. fingerprint

Class Mandatory

Format String, length up to 60

SHA-1 support is being decommissioned over the coming months and once
Description support is fully dropped, only HMAC SHA-256 will be used. In the transition
period, to use HMAC SHA-256, provide “isSHA256=” in the callback URL. It

Page 21 of 35
© SecurePay Pty Ltd
 can be appended at the end. Do not provide a value, just leave blank as is.
Once support for SHA-1 is stopped, you will not need to provide the
parameter in the callback URL but can continue to send as it will not be used
by SecureFrame.
A HMAC SHA-256 hash using your transaction password as the secret key
of:
• merchant_id|TransactionPassword|txn_type|primary_ref|amount|fp_ti
mestamp
Where the “TransactionPassword” is obtained from SecurePay Support and
maybe changed via the SecurePay Merchant Log In. All other fields must be
exactly as sent.

For a store only request (txn_type 8)

• merchant_id|TransactionPassword|txn_type|store_type|payor|fp_time
stamp
<input type="hidden" name="fingerprint"
Typical Use value="33de8f9454a62513838ce534309c76ff8ac2c925bfda0364663d836254
497899">

A.2. Transaction Fields

A.2.1. currency

Class Optional

Format String, length 3, ISO 4217 three letter currency code

Default AUD

Used to set the transaction currency sent to the bank for processing. You
must have a bank merchant facility that accepts currencies other than AUD
before using this feature.
Description Set the currency to any ISO 4217 three letter currency code. e.g., USD, NZD,
GBP, etc.
The format of the amount must match the currency. e.g., Yen has no decimal
place.

Typical Use <input type="hidden" name="currency" value="NZD">

A.2.2. display_cardholder_name

Class Optional

Format String, values “yes” or “no”

Default yes

Description By default, a Cardholder name input field is not displayed to the cardholder.

Page 22 of 35
© SecurePay Pty Ltd
 Setting the “display_cardholder_name” field to “yes” will display the
cardholder’s name input field on the payment form. This will allow the
cardholder to enter their name as part of the payment.

Typical Use <input type="hidden" name="display_cardholder_name" value="yes">

A.3. Card Storage Fields

A.3.1. store

Class Mandatory for Card Storage

Format String, values “yes” or “no”

Default no

Description “yes” to enable card storage

Typical Use <input type="hidden" name="store" value="yes">

A.3.2. store_type

Class Optional

Format String, values “PAYOR” or “TOKEN”

Default PAYOR

Type PAYOR will store the card in the SecurePay Payor database. The
“primary_ref” field will be used as the Payor ID unless overridden with “payor”.
Description Type TOKEN will either create and store a new token that represents the card
number or return a pre-existing token if the card has been stored previously.
Tokens are stored as non-editable Payors.

Typical Use <input type="hidden" name="store_type" value="payor">

A.3.3. payor

Class Optional if store_type=PAYOR

Format String, length up to 20

Default If not specified, primary_ref is used

The Payor ID to store with the Payor. This will become the Transaction
Description Reference for future triggered payments against that Payor unless overridden
with “payor_ref”

Typical Use <input type="hidden" name="payor" value="MyPayorID">

Page 23 of 35
© SecurePay Pty Ltd
A.3.4. payor_ref

Class Optional

Format String, length up to 30

Sets the Transaction Reference for future triggered payments. If not set, the
Description system will log the Payor as the Transaction Reference when a payment is
triggered.

Typical Use <input type="hidden" name="payor_ref" value="MyTransactionReference">

A.3.5. standing_instruction_type

Class Optional

Numeric, values “1”, “2” or “3”

Format • “1” for Recurring

• “2” for Instalment
• “3” for Unscheduled Credential On File (UCOF)

If no value is passed and

• txn_type = 8 (Store only) OR
• txn_type = 0 (Payment) and store = yes
Default

Then this field will default to “3” which is Unscheduled Credential on File
(UCOF). Otherwise, it will pass the same value received in the request to the
bank

This field is available not available yet. We will advise you of the date
and provide detailed instructions ahead of the changes.
This field is only applicable to Visa and Mastercard cards only and on
selected acquiring banks (NAB and fiserv FDMSA).
Standing instructions can be of three types:
• Recurring – type of payment that is processed at fixed, regular
intervals for an ongoing service e.g. gym membership.
• Instalment – type of payment that is processed at fixed incremental
payments made towards a single purchase at regular intervals and
Description
stop once the balance is paid off e.g. four $100 monthly payments
towards a sofa that costs $400.
• Unscheduled Credential On File (UCOF) – type of payment that is
used for adhoc payment triggered using a stored card e.g. an auto
top-up of an account whenever the amount falls below a certain
threshold.
If this is passed, the card scheme will send a unique identifier called Standing
Instruction ID that links to the payment history between the customer and
merchant. SecurePay will store the SIID against the payor or token and will
pass the value in subsequent transaction.

Page 24 of 35
© SecurePay Pty Ltd
 Typical Use <input type="hidden" name="standing_instruction_type" value="1">

A.3.6. customer_code

Class Optional

Format String, length up to 30

An optional field available for merchants to identify a customer and is

associated with a Payor ID. For any payor created with a customer code, it
Description
should always be passed along with the payor ID in all types of requests (add,
edit or delete). A payorID and customer code must be a unique combination.

Typical Use <input type="hidden" name="customer_code" value="MyCustomerCode">

A.4. FraudGuard Fields

A.4.1. billing_country

Class Optional

Format String, length 2, country code

Default None

Description Payee’s Country two letter code

Typical Use <input type="text" name="billing_country" value="AU">

A.4.2. delivery_country

Class Optional

Format String, length 2, country code

Default None

Description Order delivery country two letter code

Typical Use <input type="text" name="delivery_country" value="AU">

A.4.3. email_address

Class Optional

Format String, length less than 30

Default None

Description Payee’s email address

Page 25 of 35
© SecurePay Pty Ltd
 Typical Use <input type="text" name="email_address" value=”test@[Link]">

A.5. Surcharge Fields

A.5.1. surcharge

Class Mandatory for Surcharging

Format String, values “yes” or “no”

Default no

Description “yes” to enable surcharge calculation and result parameters

Typical Use <input type="hidden" name="surcharge" value="yes">

A.5.2. surcharge_rate

Class Optional

Format Numerical, 0.0001 to 99.9999

Default 0

Percentage surcharge to apply across all card types. May be overridden by

Description
applying individual card type rates.

Typical Use <input type="hidden" name="surcharge_rate" value="1.00">

A.5.3. surcharge_fee

Class Optional

Format Numerical, integer, 0 to 999999 cents (or base currency unit)

Default 0

Description Fee amount to be added to the payment amount for all card types.

Typical Use <input type="hidden" name="surcharge_fee" value="100">

A.5.4. surcharge_rate_v/m/a/d/j

Class Optional

Format Numerical, 0.01 to 99.9

Default 0

Page 26 of 35
© SecurePay Pty Ltd
 Percentage surcharge to apply to a specific card type. Overrides
Description
“surcharge_rate”.

Typical Use <input type="hidden" name="surcharge_rate_v" value="1">

A.5.5. surcharge_fee_v/m/a/d/j

Class Optional

Format Numerical, 0 to 999999 cents (or base currency unit)

Default 0

Fee amount to be added to the payment amount for a specific card type.
Description
Overrides “surcharge_fee”.

Typical Use <input type="hidden" name="surcharge_fee_v" value="100">

A.6. Transaction Flow Fields

A.6.1. display_receipt

Class Optional

Format String, values “yes” or “no”

Default yes

Define which system displays the receipt page to the card holder. “Yes”
Description means SecurePay displays the receipt page. To redirect to your own receipt
page set this value to “no” and use the return_url parameter.

Typical Use <input type="hidden" name="display_receipt" value="no">

A.6.2. return_url

Class Optional

Format String, fully qualified URL

The URL of the page on the Merchant web site that accepts transaction result
data as POST elements.
The page may be almost any form of web page, including static HTML pages,
CGI scripts, ASP pages, JSP pages, PHP scripts, etc, however cookies or
Description other forms of additional information will not be passed through the Payment
Gateway.
The “return_url” must be a URL for a publicly visible page on a web server
within a domain that is delegated to a public IP number. Internal machine
names, such as "localhost", Windows-style machine names, and privately
translated IP numbers will fail.

Page 27 of 35
© SecurePay Pty Ltd
 If “display_receipt” is set to “yes”, this is the URL of the button on the hosted
result page.
If “display_receipt” is set to “no”, this is the redirect URL following a
transaction.
Your web host cannot use Server Name Indicators (SNIs) for determining
which SSL certificate to serve. This is not supported by SecurePay’s systems.

<input type="hidden" name="return_url"

Typical Use
value="[Link]

A.6.3. return_url_text

Class Optional

Format String, length up to 30 characters

Default none

Defines the text on the hosted result page button that takes the card holder to
Description
the next step in the process.

Typical Use <input type="hidden" name="return_url_text" value="Continue">

A.6.4. return_url_target

Class Optional

Format String, values “self”, “top”, “parent” or “new”

Default none

Defines the target of the hosted result page button that takes the card holder
Description to the next step in the process. Useful for iFramed pages to take the process
out of the iFrame.

Typical Use <input type="hidden" name="return_url_target" value="parent">

A.6.5. callback_url

Class Optional

Format String, fully qualified URL

The URL of the page on the Merchant web site that accepts transaction result
data as POST elements.
Description The page may be almost any form of web page, including static HTML pages,
CGI scripts, ASP pages, JSP pages, PHP scripts, etc, however cookies or
other forms of additional information will not be passed through the Payment
Gateway.

Page 28 of 35
© SecurePay Pty Ltd
 The “callback_url” must be a URL for a publicly visible page on a web server
within a domain that is delegated to a public IP number. Internal machine
names, such as "localhost", Windows-style machine names, and privately
translated IP numbers will fail.
Your web host cannot use Server Name Indicators (SNIs) for determining
which SSL certificate to serve. This is not supported by SecurePay’s systems.
SHA-1 support is being decommissioned over the coming months and once
support is fully dropped, only HMAC SHA-256 will be used. In the transition
period, to use HMAC SHA-256, provide “isSHA256=” in the callback URL. It
can be appended at the end. Do not provide a value, just leave blank as is.
Once support for SHA-1 is stopped, you will not need to provide the
parameter in the callback URL but can continue to send as it will not be used
by SecureFrame.

For HMAC SHA-256 fingerprint

<input type="hidden" name="callback_url"
value="[Link]
Typical Use
For SHA-1
<input type="hidden" name="callback_url"
value="[Link]

A.6.6. cancel_url

Class Optional

Format String, fully qualified URL

Default Uses the return_url if not present.

The URL of the page on the Merchant web site that accepts transaction result
data as POST elements when the card holder clicks a Cancel button on a
hosted page.
The page may be almost any form of web page, including static HTML pages,
CGI scripts, ASP pages, JSP pages, PHP scripts, etc, however cookies or
other forms of additional information will not be passed through the Payment
Gateway.
Description The “cancel_url” must be a URL for a publicly visible page on a web server
within a domain that is delegated to a public IP number. Internal machine
names, such as "localhost", Windows-style machine names, and privately
translated IP numbers will fail.
Note: some result parameters may not be populated depending on the point
of cancellation of the process.
Your web host cannot use Server Name Indicators (SNIs) for determining
which SSL certificate to serve. This is not supported by SecurePay’s systems.

<input type="hidden" name="cancel_url"

Typical Use
value="[Link]

Page 29 of 35
© SecurePay Pty Ltd
A.6.7. confirmation

Class Optional

Format String, values “yes” or “no”

Default yes

By default, a Confirmation page is displayed to the cardholder, after the card

details have been entered. This is to allow the cardholder to review the details
Description (and edit as required) prior to initiating the payment.
Setting the “confirmation” field to “no” will bypass this default confirmation
step.

Typical Use <input type="hidden" name="confirmation" value="no">

A.7. Look and Feel Fields

A.7.1. template

Class Optional

Format String, values “default”

Default default

Description Defines which hosted page template is displayed to card holders.

Typical Use <input type="hidden" name="template" value="responsive">

A.7.2. primary_ref_name

Class Optional

Format String, length up to 30 characters

Default Invoice Number

Description Defines the label on the hosted pages for the Primary Reference field.

Typical Use <input type="hidden" name="primary_ref_name" value="Order Number">

A.7.3. page_header_image

Class Optional

String, fully qualified URL. HTTPS method only. Must end in one of gif, jpeg,
Format
jpg, png. Valid images only.

Default none

Page 30 of 35
© SecurePay Pty Ltd
 Description URL of an image to be used as the header of the hosted pages.

<input type="hidden" name="page_header_image" value="

Typical Use
[Link]

A.7.4. page_footer_image

Class Optional

String, fully qualified URL. HTTPS method only. Must end in one of gif, jpeg,
Format
jpg, png. Valid images only.

Default none

Description URL of an image to be used as the footer of the hosted pages.

<input type="hidden" name="page_footer_image" value="

Typical Use
[Link]

A.7.5. page_title

Class Optional

Format String, length up to 30 characters

Default Invoice Payment

Description Defines the title text on the hosted pages.

Typical Use <input type="hidden" name="page_title" value="Pay Your Invoice">

A.7.6. card_types

Class Optional

String, bar “|” separate values from VISA, MASTERCARD, AMEX, DINERS,
Format
JCB, PAYPAL

Default Visa, MasterCard

Defines the card types accepted. This must be a subset of the card types you
Description
accept.

Typical Use <input type="hidden" name="card_types" value="VISA|MASTERCARD">

A.7.7. page_style_url

Class Optional

Page 31 of 35
© SecurePay Pty Ltd
 Format String, fully qualified URL

The URL of the page on the Merchant web site that provides styling for the
Description hosted page. Styles override the default page styles. Images embedded by
be fully qualified URL’s. All JavaScript and malicious code will be removed.

<input type="hidden" name="page_style_url"

Typical Use
value="[Link]

Appendix B: Results Fields

B.1. Standard Result Fields
Field Description

The one-digit summary of the transaction result

1 = Approved
summary_code 2 = Declined by the bank
3 = Declined for any other reason
Use “rescode” and “restext” for more detail of the transaction result.

The primary indicator of the transaction result.

Bank response or internal error code numbers used to determine the
rescode transaction result. Rescode's of 00, 08 and 11 indicate approved
transactions, while all other codes represent declines. A full list of response
codes is available for download from the SecurePay website.

The associated text for each "rescode". For bank response codes 00 – 99,
restext this field is generated by the bank's payment systems. All other codes have
the "restext" generated by SecurePay.

The value of the primary_ref parameter from the transactions request. This
refid value is returned to the Merchant's processing system to allow matching of
the original transaction request.

txnid The bank transaction ID. This string is unique at least per terminal, per bank
and per settlement date. This value is required to be re-entered along with
other details of the original payment when processing refunds.

The bank settlement date. This is the date the funds will be settled into the
merchant's account. The date will correspond to today's date until the bank's
settdate
cut-off time (typically 6-11pm), then roll to the following business day. The
settlement date is returned in the format "YYYYMMDD".

pan The masked card number of format first six…last three. e.g., 444433…111

expirydate The four-digit expiry date entered by the customer. e.g., 0813

merchant The merchant_id value used for the transaction

Page 32 of 35
© SecurePay Pty Ltd
 The GMT (UTC) time used for the response fingerprint of the format
"YYYYMMDDHHMMSS". This value must be used when generating a string
timestamp to compare to the response “fingerprint” value to validate the response. The
time component must be in 24-hour time format.

The amount in the base unit of the currency, typically cents for Australian
amount Dollars. e.g., $104.23 will be 10423.

A string used to validate the transaction output.

SHA-1 support is being decommissioned over the coming months and once
support is fully dropped, only HMAC SHA-256 will be used. In the transition
period, to use HMAC SHA-256, provide “isSHA256=” in the callback URL.
Do not provide a value, just leave blank as is. Once support for SHA-1 is
stopped, you will not need to provide the parameter in the callback URL but
can continue to send as it will not be used by SecureFrame. A HMAC SHA-
256 hash using your transaction password as the secret key of the following
fields in order, separated by “|”:
For txn_type 0-7:
merchant, transaction password, reference, amount, timestamp,
summarycode
For Example:
fingerprint ABC0001|txnpassword|MyReference|1000|20220228025627|1
is HMAC SHA-256 hashed to give:
0662c9d11c12d3cb15986c53b95e053691b33e43c40bec5ad70b827
c01229771
For txn_type 8:
merchant, transaction password, reference, amount, timestamp,
summarycode
For Example:
ABC0001|txnpassword|payor|TestPayorID|20220228025627|1
is HMAC SHA-256 hashed to give:
599562e82101f8202d1965c1124340fa218a76a91fcbdeed0b106012
8d16ef6a

The card type used for the transaction. This will be one of:
• “Visa”
• “MasterCard”
cardtype
• “American Express”
• “Diners”
• “JCB”
• “PayPal”

B.2. Preauthorisations
Preauth fields are only returned when “txn_type” is set to a preauth transaction type on input.

Page 33 of 35
© SecurePay Pty Ltd
 Field Description

The bank pre-authorisation ID returned by the payment gateway. This value

preauthid
is used when sending a pre-authorisation complete transaction via XML or
Batch.

B.3. FraudGuard Result Fields

FraudGuard fields are returned in addition to the Standard Result Fields if your account is
enabled for FraudGuard by the SecurePay Support team and the “txn_type” includes the
FraudGuard option.

Field Description

FraudGuard response code if “txn_type” includes FraudGuard. Returns

afrescode
“400” if the transaction passes FraudGuard tests. Returns a different string
depending on the type of fraud detected.

FraudGuard response text. Used if the “afrescode” is not 000. Contains a

afrestext description of the FraudGuard result.

B.4. Card Storage Result Fields

Card storage fields are returned in addition to the Standard Result Fields if the input field “store”
“yes” on input.

Field Description

The one-digit summary of the storage result:

stsummarycod • 1 = Successful
e • 2 = Unsuccessful
• 4 = Cancelled by user
Use “strescode” and “strestext” for more detail of the storage result.

Storage code Returns “800” if the Payor or Token was successfully stored.
strescode
Returns a different string if the storage failed. The “strestext” describes the
failure reason.

strestext Storage response text. Contains a description of the storage result.

If “store_type” is set to “payor” (or absent - default), the “payor” field will be
Payor returned in this result field.

If “store_type” is set to “token”, the system-generated token will be returned

in this field. If the card has never been stored before, this will be a new
token
value. If the card has been stored previously, the stored value will be
returned.

If customer_code is provided in the request, the same value will be returned

customercode
in this field

Page 34 of 35
© SecurePay Pty Ltd
 (Not yet available) The same standing_instruction_type value will be
standinginstruct returned in this field.
iontype Applicable to Visa and Mastercard cards only and on selected acquiring
banks (NAB and fiserv FDMSA).

(Not yet available) If store is set to “yes”, the card scheme will send back in
the response a unique identifier called Standing Instruction ID (SIID) on the
first transaction that links to the payment history between the customer and
standinginstruct merchant. SecurePay will store the SIID against the payor and will pass the
ionid value in subsequent transaction.
Applicable to Visa and Mastercard cards only and on selected acquiring
banks (NAB and fiserv FDMSA).

B.5. Surcharge Result Fields

If “surcharge” is set to “yes” on input or the fields are set in your account, the following additional
fields are returned:

Field Description

The amount passed to the system, prior to the addition of the surcharge, in
the base unit of the currency, typically cents for Australian Dollars. E.g.
baseamount
$104.23 will be 10423. This amount added to the “suramount” equals the
“amount”.

The surcharge amount in the base unit of the currency, typically cents for
suramount Australian Dollars. E.g. $104.23 will be 10423. This amount added to the
“baseamount” equals the “amount”.

The surcharge rate in percent used to calculate the surcharge. E.g. 1% =

surrate
“1”.

The surcharge fee added to the amount amount in the base unit of the
surfee
currency, typically cents for Australian Dollars. E.g. $104.23 will be 10423.

Page 35 of 35
© SecurePay Pty Ltd