In this tutorial, we will cover SecureFrame’s advanced features. Some advanced features require enablement from SecurePay, while others can be immediately implemented into the standard implementation.
The following advanced features can be implemented immediately into the standard implementation of SecureFrame.
By default, SecureFrame will display the receipt page to the customer. You can choose to display your own receipt page to the customer by including the following HTML field in your requests.
<input type="hidden" name="display_receipt" value="no">
Your customer will then be redirected to the URL that you define in the "return_url" field.
<input type="hidden" name="return_url" value="http://www.mysite.com.au">
The card details used in a payment made through SecureFrame can be optionally stored in SecurePay’s system against a unique identifier. This unique identifier can then be used instead of the card details for subsequent payments known as triggered payments. Triggered payments can be performed via our XML/API, Batch or Merchant Login methods.
In order to store card details, you will need to include the following HTML field in your requests:
<input type="hidden" name="store" value="yes">
You can use 3 methods of card storage:
1. Payor
This is the default card storage method.
With Payor storage, you define the Payor ID to store with the card. Cards and Payor IDs can be edited via the Merchant Login.
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".
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">
Set the value of "payor" to your required value
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.
Tokens can be used in third-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, use "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">
3. Stored Transaction Reference
When triggering a payment from a stored card (either '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.
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">
In this example, the Payment Reference ID and the stored Transaction Reference for future triggering are the same.
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">
Surcharging may be applied across all card types (Visa, MasterCard etc), or set individually per card type.
Surcharging can be either or both:
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">
There are several options to control how the hosted pages are displayed to your customers. This is controlled by the optional "template" parameter.
Set "template=default" to use the full screen payment option. If the template parameter is omitted, this is the default.
Set "template=iframe" to use the iFrame version. This version displays only the input fields, confirmation text and form buttons. This allows for seamless integration into your website.
Set "template=responsive" to use the Responsive version. This version allows the customer’s web browser to adjust the layout and design of the payment page to the dimensions of the browser window. The payment page will exist outside of an iFrame.
Tip: use the Return URL text and target options to control the payment flow from within the iFrame.
Example: Set the template to iFrame
<input type="hidden" name="template" value="iframe">
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="https://www.mysite.com.au/header.jpg">
<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 the SecureFrame Reference section.
A pre-authorisation is a transaction that reserves funds on a card account. The Merchant can then complete the transaction at a later date and receive the funds. If the pre-authorisation is never completed, it expires usually after 5 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">
'The following Advanced Features require enablement by SecurePay before they can be implemented. Please contact SecurePay Sales for more information and pricing
You can optionally configure the SecureFrame payment page to display a Cardholder Name field. This field will be logged within the transaction details in the Merchant Login. To do this, you will be required to send through the following field in your requests:
<input type="hidden" name="display_cardholder_name" value="yes">
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).
Once your account is enabled for PayPal, more information regarding the technical implementation can be found in the SecurePay Developer Centre documentation for SecureFrame.
Example: Set the accepted tenders to Visa, MasterCard and PayPal
<input type="hidden" name="card_types" value="VISA|MASTERCARD|PAYPAL">
SecurePay's FraudGuard provides merchants with greater control in detecting fraud and fraudulent transactions before they occur. Stopping fraudulent transactions also helps to minimise and avoid chargebacks from the bank. FraudGuard lets you easily set up your own fraud screening rules from within the Merchant Login.
FraudGuard must be activated on your SecurePay account, before it can be enabled by setting the "txn_type" field in SecureFrame.
See the SecureFrame Reference section for more details regarding setting the "txn_type" field and other FraudGuard request and result fields.
For pricing and more information on getting this service enabled, please contact SecurePay Sales
3D Secure is an online service designed to make online shopping transactions safer by authenticating a cardholder’s identity at the time of purchase. This service is known as Verified by Visa and MasterCard SecureCode. A transaction using Verified by Visa/SecureCode will redirect cardholders to the website of their card issuing bank. The cardholder may then be requested by their bank to enter a password to be authenticated. If a customer is not registered with 3D Secure, they are still able to make a purchase from you web site.
It must be activated on your SecurePay account, before it can be enabled by setting the "txn_type" field.
For more details regarding setting the "txn_type" field, see the SecureFrame Reference section
For pricing and more information on getting this service enabled, please contact SecurePay Sales SecurePay Sales.