Add a financial transaction - digital guide

Add secure financial transactions to a site, including payment cards.

Before you begin

What are online financial transactions?

Online financial transactions see money transferred via the internet. Online financial transactions incorporate a range of security measures to protect sensitive financial and personal information.

Why do online financial transactions?

Online financial transactions are essential to delivering government services. Citizens are increasingly managing their finances online, and government services must keep up with this shift.

What does the Victorian Government recommend?

All Victorian Government online services financial transactions should be consistent, accessible and trusted. They must meet your customers’ expectations for their preferred device and should adhere to our state government and policy guidelines for security, identity, e-payment and privacy.

What standards must be met?

Payment card industry (PCI) security standards

The Payment Card Industry Security Standards Council set up the PCI security standards to protect cardholder data. These global standards govern all merchants and organisations that store, process or transmit this data. The major payment card brands, for example, Visa, enforce compliance.

Australian Competition and Consumer Commission rules for surcharges

If you pass any credit card or merchant surcharges to the consumer, you must say how much this is before the transaction is complete.

Security

Comply with the Privacy and Data Protection Act 2014. Refer to secure your service - digital guide, and the security framework and standards on the Commissioner for Privacy and Data Protection website, for more information.

Branding

Apply Brand Victoria. Refer to brand Victoria - digital guide (specifically written for digital).

Privacy

Comply with the Privacy and Data Protection Act 2014.

You’ll need to provide a collection notice. Refer to protect privacy - digital guide for more information.

Accessibility

To comply with the Australian Human Rights Commission’s Disability Discrimination Act, and the WoVG standard ‘Conform to Level AA of version 2.1 of the Web Content Accessibility Guidelines (WCAG 2.1)’, your digital presence must comply with the Web Content Accessibility Guidelines Version 2.1 (WCAG) AA standard.

If your audience is primarily people with a disability (for example, National Disability Insurance Scheme (NDIS) clients), your site must pass the test for the AAA standard.

Refer to make content accessible - digital guide for more information.

Manage public records

The Public Record Office Victoria (PROV) (under Section 12 of the Public Records Act 1973) sets the standards for managing the public records your department or agency create. Always check with your department’s or agency’s records or information management specialist first for the approach to compliance.

Refer to manage online records - digital guide for more information or the PROV website.

E-payment

All e-payment procedures must adhere to the Standing Directions (Victoria’s Minister of Finance) for money taken by credit card, or other electronic media.

Getting it approved

Your Digital Management Committee (DMC) will need to approve any actions relating to online financial transactions. Check your agency or department’s intranet for the relevant contact details, or contact your local IT support or ICT manager for guidance.

Best-practice

While each financial transaction varies depending on its purpose and audience, there are some best practice principles you can follow. For a good overview of best practice design read Web Form Design by Luke Wroblewski and the design forms - digital guide.

Create a logical flow

What is the most logical process flow from start to end, how is the information best grouped, and does the transaction require multiple steps? Refer to design forms - digital guide for recommendations.

Good process design is more important than the interface – start with the payment types, the PSP and back-end integration, then add the icing of HCI design on top – the type of payment will influence the design of the screen or interface far more than the guidelines from Apple – for example, to add ‘Apple Pay’ in an app you embed a button, whereas for a card authentication you will need multiple calls and authentication processes, which means more places for things to go wrong etc.

Get the basics right then focus on the UX and interface and add more detail on the exceptions in the process – craft practical user help, for example, how to cancel or back out of a transaction, how to prevent browser refresh performing another transaction if people refresh before a process has completed etc.

Make systems efficient

The systems you put in place should make the transactions as easy as possible for your customers. For example, instead of users selecting a card type for credit card transactions, use the card number to work out the type of card and the merchant fees.

Decide what you will need for your checkout and confirmation process for a payment (this could be a billing address, shipping address, proof of identity, or the address or email to send the confirmation, tax receipt and payment options) and make it as easy as possible for customers to provide those details.

Create helpful systems

You should put visual and functional aids in place to make the process easier to understand. For example, you could interface functionality like grouped numbers with auto-tabbing aid legibility and usability, or show a picture and location for CVC (three-digit code on the back of the card.)

Help customers to keep records

Consider how you will show payment summaries, both before and after the payment. You will also need to decide how you will generate and show receipts, and what print and email functions you will offer.

Decide how you will show records of previous transactions, for transactions inside account logins and for transactions outside of account logins to allow your customers to retrieve records.

Keep your knowledge up-to-date

It’s also worth keeping up to date with the latest developer and human-computer interaction (HCI) guidelines for the main operating systems and browsers you’ll build for, that is iOS, Safari, Android, Internet Explorer, Chrome, Windows etc. How each of these work with financial transactions often changes, and often without notice.

Use these sites:

The UK government has a well-developed digital program and a central payment capability.This is a good place to start.

The official guide to the GOV.UK Pay API for developers and service managers - an example of a good approach and comparator for best practice.

GitHub and the Open Web Application Security Project (OWASP) are two online software communities working (in part) on financial transactions.

Google Web Payments API

Other standards: W3C (web accessibility standards) has a web payments page which signposts the Web Payments Interest Group and the Web Payments Community Group.

Device preferences for financial transactions

It’s impossible to predict what device your customers’ might prefer to use for a future financial transaction. It’s wise to start by investigating device use – you can’t assume what people preferred to use even six months ago is still true today.

Identify your user’s device preferences

Find out which devices the user will use for the transaction. Refer to the research user experience - digital guide for tips on researching user needs and preferences.

Common devices include phones, tablets, watches and wearables, desktop and laptop computers, TVs and virtual reality/augmented reality devices.

Consult developer centres

Visit the respective developer centres online for each device or operating system, review their Human Computer Interface (HCI) guidelines, and check for device compliance, integration, feasibility or experience issues. Some useful developer centres include:

Tailor your content to these devices

Think through the display considerations for your devices. Consider the need, if any, for variances in approach to cater for different devices and screen sizes. Can you have one design that works for all devices, or will you need to re-scale how your transaction displays on different devices?

The Brand Victoria Guidelines list screen sizes and breakpoints for iOS, and notes for ‘responsive design’ (works on any device.) Also, look at Google responsive design, with an excellent break point diagram.

Payment types

Know your options

You should build an understanding of the current payment types that are available, and how they work with the services you’re building. Payment types are generally native applications, websites or a combination of both. Are you dealing with one-off payments, instalments or payment plans? What are the boundaries for service — where does Victoria hand off to the payment service provider, acquirer, merchant services provider?

Use statistics

You can extract useful statistics from the site or app you’re building the transaction for. This could include the current volume of payments, the frequency of payments and preferred ways to pay. Keep in mind that statistics from existing systems have an inbuilt bias towards the payment services that are already offered.

Do user experience research

Is there any user research on transactions, or guidance on how to implement best practice for your type of transaction? Consulting UX Mistakes Made by Financial Institutions And How to Avoid Them(opens in a new window) is a good start to help you incorporate UX research findings into your transactions.

Also read the research user experience - digital guide (complete with several templates.)

Payment methods

Identify which payment types you need to cater for. Visit the following developer centers for information specific to each payment method:

Look into preferred suppliers

What agreements do we (WoVG, departments, and agencies) already have for preferred suppliers of payment gateway services? What are the contractual obligations and service level agreements? This may have a bearing on the Payment methods you can use. How is the current service performing for reliability, usability and cost? Ask the SDP Community of Practice via the Innovation Network (VPS access only)(opens in a new window) if you’re not sure.

The Victorian Government (through Services Victoria) wants to reduce the cost of using multiple vendors to handle financial transactions. The eventual goal is to use as few vendors as possible to make transactions consistent, familiar and predictable, while also providing flexibility for the customer’s preferred method of payment.

Have alternatives

There are some cases when your regular payment system won’t be appropriate or possible. Your service could be unavailable – what will show up in this case? You should also consider alternatives for urgent transactions and how those are communicated.

Security and privacy

When handling financial transactions online, and to protect your users and help them to feel secure, you’ll need rigorous security and privacy measures. Consider the level of security and authentication your transactions need. You need to decide how you will manage proof of identity in transactions, when and how to ask for identity verification.

Keep in mind your transaction needs to comply with Victorian State Government regulations for security, e-payment, authentication and managing personal information. You should be aware of the related government documents that apply to capturing and storing credit card details, collecting personal information, processing transactions, security and authentication.

For a better understanding of security and privacy refer to secure your service - digital guide and protect privacy - digital guide.

Fees

Consider what merchant fees the consumer will pay for a transaction. How will you tell them how much these are? Decide how GST components will be shown. Does GST apply to the whole or just parts of the transaction? You will also need to show respective merchant fees if they apply.

The Australian Competition and Consumer Commission advises if you pass any credit card or merchant surcharge to the consumer, you must say how much it is beforehand, and not during or after the transaction is complete.

Service providers

You will need to choose a service provider that offers technology which will meet the business requirements for the service you’re building. Look for service providers that:

Offer skinnable options

Investigate whether the service provider has skinnable options that can create a seamless transaction across websites.

Are trustworthy and reliable

To guarantee a reliable service, choose a web or payment service that has guaranteed uptime (for example, 99.98%) and redundant servers (copies of the data at another physical site) with strong security.

Also consider whether the service provider has logos and branding that are part of the service and whether branding or the type of information requested will impact citizens’ perceptions of trust, privacy and security.

Offer reporting

Investigate whether the transactions can be tracked or reported on using either your web analytics tool or a third-party analytics service. Transactions made via mobile apps may require separate ’instrumentation’ to collect usage data including information on where people abandon a transaction.

Meet regulations

Ensure that the transactions offered by the provider are made only using web servers that follow https protocols and have current trusted third-party SSL certificates.

Personalisation features

Base personalisation on previous behaviour

If you show a list of transactions, or options, which are the most likely to be needed based on previous behaviour, or seasonal variation? For example, you could pre-fill any preferences you already know about the individual, such as their preferred payment type.

Personalise for efficiency

Think through where a personalisation default makes sense for a payment and use the default if it translates to speed and accuracy. For example, you could pre-fill information from the customer’s existing account (e.g. contact details) to save them time.

When is it appropriate to pre-fill details?

Smart defaults and pre-filling information in forms can expedite their completion, but should only be considered if they benefit the majority of registered users. Pre-filling using account details is not always helpful or appropriate. For more detail on form design and pre-filling best practice go to design forms - digital guide.

Delivery and collection

If you offer a physical product you need to consider delivery and collection options.

Turn around times

Consider how much control you have over delivery turnaround times, and what is a typical delivery turnaround time expected to be. How and when will you communicate that?

Price

Consider how the price of postage options will impact the overall price and when will that be shown. How will processing turnaround times impact the overall price, and when will that be shown?

Tracking

What tracking options will you offer? For more information, consult the following developer centres:

Support your users

If your financial transactions aren’t working properly, you will need to have systems in place to support users. Consider how you will find out if your transaction or the checkout process isn’t running properly, and how you will cope with it.

In what cases can the service provider respond to urgent support issues? Who will respond to a user’s question and when? What are the service level agreements for support?

Glossary

Break point - the point at which responsively designed content will respond and resize itself.

Native application - specific operating system or platform, for example, iOS, Windows, Linux Android.

Payment Gateway - a merchant service provided by an e-commerce application service provider. It authorises credit card or direct debit payments online. For example, SecurePay.

Responsive design - web content that detects the visitor's screen size and orientation and changes the layout accordingly.

Updated