FAQ
- Joseph De Jesus IV
Frequently Asked Questions and answers to assist in understanding and using the Payrix Integrated Platform.
Authorised Contact
For any requests to change details of the Business, the request must be received from a listed Authorised contact on the account. This is determined when the Business is boarded and the Payrix Portal can list up to 6 authorised contacts and 6 email addresses.
If any changes to business details are required, please email our Client Success team at admin@payrix.com.au. As noted above, the request must be received from a listed authorised contact.
Changes to business details can include but not limited to:
Add, update or remove listed authorised contacts - (can list up to 6)
Add, update or remove listed email addresses - (can list up to 6)
Add, update or remove recipients from reporting correspondences Payrix send out
Update general business details, such as Phone number, address
Some detail changes require forms to be completed. These can include the below changes:
Should a request not be received from an authorised contact AND from an authorised email, the request will not be processed. This is a security policy set in place to protect both Payrix and the business.
Q: How to manage payer paid fees?
A: This is managed by Payrix as the fees are set on the account level by our Client Success team.
If you are using one of Payrix’s Hosted Payment pages, the fees will be automatically displayed to the payer on the payment page.
If you have built and are using your own pages, you need to ensure that the customer making a payment or signing up to a Direct Debit Agreement is aware of any surcharges involved.
Q: How to use Test Bank Account details
A: Within the Payrix Sandbox environment, you can test bank account details by using any numbers that match the rules for the country the account is set in.
Australia = BSB (123456) / Account Number (12345678)
New Zealand = BSB (123456) / Account Number (1234456789)
Q: How to use Test Card details
A: Within the Payrix Sandbox environment, you can test card transasctions using the card examples below:
CVC = Any 3 digit number
Expiry Date = Any future date
Card Type | Test Card Numbers |
|---|---|
| 4111111111111111 |
| 5353535353535351 |
| 378282246310005 |
| 6011111111111117 |
| 3530111333300000 |
| 30569309025904 |
Q: How to test wallet payments (Apple Pay / Google Pay) in Sandbox
A: Your device will need to be linked to either Apple Pay or Google Pay in order for the type of wallet payment to be available to select on our Hosted Payment Page. Any transactions pushed through the Sandbox environment will not process / deduct funds from your account.
Q: How to test declines in Sandbox?
A: When using the test API, the transaction amount gives you the ability to test both successful and failed payments. When the transaction amount has zero cents or a number of cents other than the ones listed below, the test transaction will always be successful. If you provide one of the following numbers for the number of cents you will receive a transaction failed response with the corresponding reason:
31 = Invalid Account
54 = Expired card - Card Only
51 = Declined
61 = Insufficient Funds
96 = Technical failure - Card Only
Q: How to determine the result of the transaction for a Bank Account / Card Debit, BPAY and real-time card transaction?
A: To identify the transaction result will depend on the type of transaction. See below:
Scheduled Bank Account or Card Debit (2 Business day setttlement)
Call our GET Search for transaction status changes around 9AM AEST daily which will pull a set of all transactions for your business that have had a change of transaction status.
When a transaction is initially processed in the debit run, the transaction status will be a ‘C' (Cleared - Card Debit) or a 'P’ (Pending - Bank Debit)
On the 2nd business day, the result will be returned by the bank which will change the status to ‘S' (Settled) or 'R’ (Rejected - Transaction failed)
Following the above API, use our POST Acknowledge transaction status change to acknowledge the transactions and remove them from the data set when you next call the Get New Status Search above.
If the transaction status changes again after you have removed it from the data set, it will be returned in the GET Search for transaction status changes to notify you of the change in status.
e.g. Search for specific types of transactions (single or list)
PDB = Payer Debit Bank
PDC = Payer Debit Card
BPAY
Call our GET Search for transaction status changes around 9AM AEST daily which will pull a set of all transactions for your business that have had a change of transaction status.
Following the above API, call our POST Acknowledge transaction status change to acknowledge the transactions and remove them from the data set when you next call the Get New Status Search above. If the transaction status changes again after you have removed it from the data set, it will be returned in the GET Search for transaction status changes to notify you of the change in status.
BPAY transactions are typically a next day response if processed before 3PM. If the BPAY transaction is initiated after 3PM, the result will be returned the day after next.
e.g. BPAY querystring
Real-time card payment (eCommerce)
When processing a real-time tokenised card transaction, the result is returned in real-time.
If the response returns a statuscode of 'C' or an 'S’ you can presume the transaction was successful.
If you are using Payrix merchant facility you will see a statuscode of ‘C' (Cleared - Processed by Payrix and debited from Payers account) immediately.
If you are using your own merchant facility, you will typically see a status of 'S' (Settled - Funds settled).
If the response returns a statuscode of 'F', the transaction was declined with the rejection reason supplied in the status description.
If you are using our Hosted Payment Page, you will use our GET Token Lookup endpoint.
Within the response body of the transaction field, if the statuscode is ‘C' or 'S’, the transaction was successful.
If you are using Payrix merchant facility you will see a statuscode of ‘C' (Cleared - Processed by Payrix and debited from Payers account) immediately.
If you are using your own merchant facility, you will typically see a status of 'S' (Settled - Funds settled).
Within the response body of the transaction field, if the statuscode is 'R', the transaction was declined with the rejection reason supplied in the status description.
Q: Reason for Rejection / Decline transaction results:
A: If a transaction is rejected with a decline reason supplied by the issuer we will return this response. Refer to Transaction Sub-Status Code.
If a transaction is rejected, some decline responses by the financial institution / card issuer return a generic reason, so it’s not always possible to know exactly why the payment was declined. If all of the information seems correct, it is best to have your customer contact their financial institution / card issuer and ask for more information. For privacy and security, financial institutions / card issuers are only obligated to discuss the specifics of a declined payment with their card holder.
Q: Why are payers set to the ‘Cancelled due to inactivity’ status?
A: Once every month the system performs an automated process that cancels inactive payers. This process is required in order to fulfil our PCI Compliance obligations which require us to have a set Bank Account and Card retention policy.
This retention process sets payers to the "Cancelled due to inactivity" status if:
Their last payment occurred over 13 months ago.
OR
They were added to the system over 13 months ago and they haven't had any payments during this time.
Once a payer has been set to a cancelled status (this includes all Cancelled statuses not just the "Cancelled due to inactivity" status) Payrix will continue to store their credit card details for a further 30 days. If the payer has not been changed to an active status within this time the system will delete their payment details.
This deletion removes their payment details for good and it is not possible to retrieve them - if the payer needs to be re-activated the business will have to re-obtain the card details from their customer.
When a payer has their payment details deleted, the system sets their payment method to a bank account with dummy details, BSB '111111' and Account Number '11111111' with account name 'C-INA'.