MYOB PAYBY SUPPORT
Have a question?
Find your answer below or contact our technical support team directly
Frequently Asked Questions
Account and setup
To register as a user of the Zendesk support system, simply follow the steps below:
1. Please click on, "Raise a support ticket".
2. You will then see the "Sign in to MYOB Payby Support" page, please click "New to MYOB Payby Support? Sign up".
3. Enter your full name, email and tick "I'm not a robot" before clicking the "sign up" button
4. You will receive an email from Zendesk with a unique link, please click on the link to verify your account and create a password.
Please raise a support ticket using the 'create a ticket' button above.
The merchant portal has been designed for Chrome, Firefox and Internet Explorer. Please update your browser, if need be, to gain full advantage of this application. The interface has been designed for a minimum screen resolution of 1024 x 768 pixels, please refer to your PC documentation for information regarding monitor configuration if your settings do not meet this requirement.
MYOB PayBy is an exclusive distributor of The ai Corporation; a leading global provider of fraud management services.
The ai Corporation RiskNet platform is widely acknowledged as the best in class. It’s real time self-service rules enable detection and prevention of fraud and other suspicious transactions, protecting the entire payment chain.
3-D Secure has been in market for a number of years to shift liability to issuer banks but is now viewed as a largely blunt instrument with fraud levels returning to higher rates.
3-D Secure 2.0 promises greater fraud prevention, with reduced disruption to the customer experience. It’s a more data driven approach to fraud detection, meaning that this is less intrusive to customers. Reducing the checkout drop off rate caused by 3-D Secure 1.0, there are now better ways to increase sales, greater fraud detection and potentially more liability shift.
Secure Remote Commerce (SRC) is a framework developed by EMVCo. SRC is the future of credit card payments to deliver a consistent and seamless checkout experience via one button for all card payments across all merchant sites.
World Wide Web Consortium (W3C) refers to their payment working group. SRC is compatible with W3C’s browser standards that will deliver even further customer and merchant capabilities.
Consumers get the same convenient experience from site to site and businesses get tokenised security. One common checkout button with data driven security.
The improved experience will be complemented by 3-D Secure 2.0 authentication, biometrics, AI-based fraud detection and monitoring services.
Businesses shouldn’t turn a blind eye on this growing issue, instead should implement a fraud management system, or implement fraud as a managed service with a fraud management provider. When comparing the fraud-fighting market, key attributes to look for include advancements in new technology, such as machine learning, real-time business intelligence and scoring, authentication approaches, historical data verification, behavioural data patterns, behavioural biometrics, and physical biometrics.
In a recent study, "Financial Impact of Fraud Study: Exploring the Financial Impact of Fraud in a Digital World,” 21% of operational spend was allocated to fraud management in 2017.
Businesses are taking a comprehensive look at the internal costs of combating fraud and evaluating the benefits of hiring a professional service provider to manage fraud on their behalf.
Outsourcing fraud management to a fraud management provider as a professional service is becoming a more popular method of managing fraud, with 24% of businesses currently outsourcing some or all their fraud mitigation efforts.
MYOB PayBy’s specialised team of experts provides support for data analysis, rules-building, and recommended best practices customised to your business. We're ahead of the latest attack methods and evolving fraud patterns so we can deal with the latest types of fraud before you're even aware of them.
The Australian Payment Card Fraud Report, 2018 reported 85% of all fraud on Australian cards, occurred mainly online. The Australian Payment Network Report, 2018 reported $561 million was fraud.
Types of transactional fraud reported by the Australia Payments Network, 2018 include:
- 85% card not present
- 7% counterfeit / skimming
- 6% Lost or stolen
- 1 % never received
- 1% fraudulent application
The Australian Payments Network, 2018 reported Australians transacted $748B in 2017, $561m was fraud. For every $1,000 spent online, 74.7 cents was lost to fraud.
The Financial Impact of Fraud Study: Exploring the Financial Impact of Fraud in a Digital World, 2017, reported it may cost merchants around 8% of annual revenue on average.
While fraud costs hurt, the bigger hit to the bottom line comes from false positives—legitimate sales incorrectly flagged as fraudulent.
When you turn down a good customer with a legitimate order, you might as well lose that customer.
False positives continue to grow, at an increase of 25% for businesses providing digital goods and 27% for businesses providing physical goods, as reported by The Financial Impact of Fraud Study: Exploring the Financial Impact of Fraud in a Digital World, 2017 report.
Chargebacks were up 60% for businesses providing digital goods and 75% for businesses providing physical goods, a result of increased sophistication of fraudsters, as reported by The Financial Impact of Fraud Study: Exploring the Financial Impact of Fraud in a Digital World, 2017 report.
Unauthorized transactions were up 33% in 2017 and accounted for nearly half of businesses average fraud losses, as reported by The Financial Impact of Fraud Study: Exploring the Financial Impact of Fraud in a Digital World, 2017 report.
Subtract 1% (average AU fraud rate) from your decline rate percentage and multiply that by the number of sales you process each year.
This will give you a rough estimate of how many false positive sales you are likely incurring.
Next, multiply those foregone sales by your average ticket total. This dollar amount will be the revenue impact of those false positives.
Here’s an example of how that might look:
Decline rate: 9% = 9,000 sales declined and/or cancelled-after-review divided by 100,000 sales.
False positives: 8,000 = 9% (your decline rate) minus 1% (average AU fraud rate) equals 8% multiplied by 100,000 sales processed.
Revenue impact: $440,000 = 8,000 false positives x $55 average ticket total.
This dollar amount won’t be perfectly accurate, but it will give you a reasonable idea of how big (or small) your problem with false positives is.
You should expect a fraud engine to detect and prevent transactional fraud right from the start. And it should analyse transactions through a combination of the rules created and machine learning.
What sets most fraud engines apart from the rest is, real-time and near real-time self-service rules for the detection and prevention of fraud and other suspicious transactions, by looking at historical data and transactional trends, calibrating actual transactions vs. chargebacks and recommending rules for future transactions in milliseconds, in turn reducing fraud losses.
Start putting plans in place, since fraudsters don’t wait for peak periods.
Manual reviews of suspicious transactions will continue to play an important role in fraud protection strategy, chances are that it could cost your business more than it should – time, efficiencies, people and money.
There are several metrics you should look at when assessing your fraud prevention efforts – monitor how much you are losing to chargebacks and keep false positives down as much as possible.
With the scale and variety of fraud evolving, make the job of your analysts more effective. We work with every business to recommend a solution, either standalone or managed as a professional service, as well as where fraud is a pain point. We also work with the business’s team of analysts to remove the mundane tasks and provide valuable insights for their fraud management strategy.
Scheme tokenisation is an initiative supported by EMVCo and a collaborative exercise by Mastercard, Visa, Amex, etc. to remove real credit card numbers from circulation.
A unique token will be generated each time a credit card is registered with a merchant for payment. Schemes and banks will be able to track all tokens associated with a credit card to improve security, customer convenience and merchant sales.
If a card is registered with a new merchant that is not compatible with previous customer behaviour, location, etc. than it’ flagged as a fraudulent transaction.
Additionally, if a card expires or is cancelled, a replacement card will be associated with existing tokens stored with businesses.
A Virtual Card Account is a single use unique card number assigned to pay each individual invoice. This number will be a unique match for the invoice the buyer has chosen to pay with this method. It is linked to a credit facility that a bank has provided to the buyer.
MYOB will process the payments on behalf of the buyer.
Suppliers will be able to receive payments straight into their nominated bank account and will reflect the buyer’s business name.
Alternatively, suppliers can apply for a merchant facility which will enable acceptance of card payments from the buyer and other buyers.
If suppliers already have a merchant facility, MYOB PayBy will arrange to have those payments settled into the nominated bank account.
The payment will be coming from the buyer, their business name will be reflected on the supplier’s statement. MYOB PayBy will be processing those payments.
Once the buyer initiates the payment, suppliers will receive the payment within T+1 business day.
Suppliers will be able to receive payments straight into the nominated bank account and will reflect the buyer’s business name.
The buyer has provided the opportunity to pay their suppliers through a unique “single use” Virtual Card Account for each individual invoice.
This means suppliers will be able to be paid earlier and the buyer will advise the supplier of the payment terms.
The Virtual Card Account number is unique for a specific invoice and will appear on the supplier statement along with the amount paid.
There is a supplier services fee.
To be in compliance with local law and AML legislation, we are required to confirm certain details and have an agreement in place to cover the new payment service.
- Business Name
- Business ABN
- Nominated Director
- BSB and Account Number
- Acquirer and Merchant ID (if applicable)
Easier reconciliation with a unique virtual card account number assigned for each individual invoice.
Improved cash flow as the buyer will now pay suppliers earlier via a unique virtual card account number that will appear on the statement.
Flexible options offered to suppliers for receiving faster payments from their buyers:
- Receive payments settled straight into the nominated bank account
- Receive a merchant facility so that you can accept card payments from other buyers or customers
- Provide your Merchant ID if you already have a merchant facility so MYOB PayBy can use the same Merchant ID to receive payments from the buyer
Feel free to call our support team on 1300 303 742 or visit our website to raise a Zendesk ticket at myobpayby.com/support
Transport Layer Security (TLS) 1.2
Transport Layer Security (TLS) is a cryptographic protocol used to establish a secure communications channel between two systems. It's used to authenticate one or both systems, and protect the confidentiality and integrity of information that passes between systems. TLS 1.0 is an updated version of the Secure Sockets Layer (SSL) protocol, and TLS 1.1 and 1.2 have built on top of that with increasingly enhanced security.
If you are communicating with MYOB (Paycorp) via an HTTPS connection to one of the following URLs on one of the following domains, then this section is for you.
|Bank of New Zealand (BNZ)
More recent versions of Java 7 (as of 1.7.0_131) and 8 support TLSv1.2 by default, so you should upgrade your Java version and that will upgrade the SSL protocol of your HTTPS connections to TLSv1.2.
In recent version of Java the support for 256-bit cryptography has been disabled by default. You will need to download Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files here:
- Java7: http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html.
- Java8: http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
Replace the local_policy.jar and US_export_policy.jar jars files in your lib/security in JRE directory.
If you are unable to upgrade Java and you are running on earlier versions of Java 7, you should be able to enable TLSv1.2 by adding following flags to your Java command line arguments:
In order to trace SSL requests, please add following flag to your Java command line arguments: -Djavax.net.debug=ssl
Please refer to the relevant technology stack documentation on upgrading to TLSv1.2
To summarise .NET:
- NET 4.6 and above. You don’t need to do any additional work to support TLS 1.2, it’s supported by default.
- .NET 4.5. TLS 1.2 is supported, but it’s not a default protocol. You need to opt-in to use it. The following code will make TLS 1.2 default, make sure to execute it before making a connection to secured resource:
- ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12
- .NET 4.0. TLS 1.2 is not supported, but if you have .NET 4.5 (or above) installed on the system then you still can opt in for TLS 1.2 even if your application framework doesn’t support it. The only problem is that SecurityProtocolType in .NET 4.0 doesn’t have an entry for TLS1.2, so we’d have to use a numerical representation of this enum value:
- ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
- .NET 3.5 or below. TLS 1.2 is not supported (*) and there is no workaround. Upgrade your application to more recent version of the framework.
For more information visit: https://blogs.perficient.com/microsoft/2016/04/tsl-1-2-and-net-support/
If you are communicating with Paycorp via Webpay Client SDK (Java, Microsoft .NET developer platform
(.NET), etc.) or via opening a direct socket connection to one of the following endpoints, then this section is for you.
|- merchants.paycorp.com.au:3006 - PYC Live
- merchants.paycorp.com.au:3007 - PYC Test
- merchants.paycorp.com.au:4006 - PYC Live (compatibility mode)
- merchants.paycorp.com.au:4007 - PYC Test (compatibility mode)
|Bank of New Zealand (BNZ)|
|- trans.buylineplus.co.nz:3006 = BNZ Live
- trans.buylineplus.co.nz:3007 = BNZ Test
- trans.buylineplus.co.nz:3008 = BNZ Test
- trans.buylineplus.co.nz:4006 = BNZ Live (compatibility mode)
- trans.buylineplus.co.nz:4007 = BNZ Test (compatibility mode)
|Please note that compatibility mode endpoints above were there for SSLv3 support only and they will not be supported after restricting SSL protocols to TLSv1.2 only. If you were using one of the compatibility mode endpoints above, please change your configuration to appropriate Live or Test endpoint once you have upgraded to TLSv1.2.|
- Microsoft .NET developer platform (.NET) API – You need to download the latest .NET SDK v3.0.0
- Webpay OLE control extension (OCX) or Active Template Library (ATL) – You need to migrate to the Microsoft .NET API. Please download the latest .NET SDK v3.0.0
- PHP/Perl/Python or any other Open SSL based technology. Please ensure that your version of OpenSSL library supports TLSv1.2 (as of OpenSSL v1.0.2). See OpenSSL 1.0.2 Notes for details.
We encourage you to use our pre-prod environment to test your TLSv1.2 upgrade. As of 3rd of April 2018 our pre-prod environment will only support TLSv1.2 SSL protocol.
Please use following domain names for all your REpresentational State Transfer (REST) calls to our pre-prod environment.
|PROD Domains||PRE-PROD Domains|
|Bank of New Zealand (BNZ)
Please use following endpoints for all your WTS Gateway socket connections.
|- test-merchants.paycorp.com.au:3006 - PYC Live
- test-merchants.paycorp.com.au:3007 - PYC Test
|Bank of New Zealand (BNZ)|
If your implementation of the MYOB PayBy (Paycorp) payment page is within an iframe on a browser, the browser determines the TLS version used. All major browsers (Chrome, Firefox, Internet Explorer, Safari and Opera) support TLS v1.2 by default. For more information about TLS browser support click here.
Can't find what you're looking for?
We're here to help, available Monday to Friday 9.00am-5.30pm AEST.Contact Support
Need help getting set up?
Check out our helpful Resource Hub for detailed digital guides and API documentationVisit the Resource Hub