We've expanded the Payment API to allow access to additional fields, enabling more comprehensive data retrieval.
In this update, the following fields have been added:
Description - The payment description Source - Where the payment originated
Source attribute
The source attribute is to indicate where the payment originated. This can be useful when differentiating payments that are made from payment requests or from a hosted pages link or even from your internal staff team using virtual terminal.
We recommend using Feeder as it provides free push notifications for changes and updates.
Production implementation date: 3rd February 2025
DDR Subscriptions - Webhooks
Receive webhooks on DDR subscriptions updates
Receive webhooks for changes to DDR subscriptions. When a DDR subscription frequency, amount or description changes you will now receive a webhook notification. This is useful in scenarios where you change the settings from the Pay Advantage portal and you require you backend to be notified about the changes. It is also very useful when a DDR amount change requires a customer to approve, you will be notified via a webhook when that has been approved and changed.
The new webhook details are:
Event
Description
Name
Direct Debit Settings Updated
Sent every time the DDR has changed its amount, description or frequency
ddr.setting_updated
Direct Debit amount change requested
This is sent every time an amount is requested to be changed on a DDR. The setting_updated webhook will be fired once the amount change has been approved.
Production implementation date: 12th November 2024
Apple Pay - Register domain
Apple pay needs domain registration
In order to use Apple pay using the WordPress plugin or the iFrame you need to register your domain so Apple is able to validate your merchant account and website. (This is not necessary for Google Pay)
The merchant dashboard now has a section where you can register for Apple pay on your domain. Once this domain has been submitted, our support team will be in contact with you to provide a file that you must host on your website. This will enable Apple pay to be used by your customers.
You can now send out a change payment account link to your customers via a simple API which returns a link. The customer will be able to follow that link and change the account the Direct Debit payments are being processed.
A much desired feature has been released where you can now cancel, pause or resume the direct debit subscription from the API. Simply send in the status you want to change the direct debit to. A webhook will be triggered to notify a change has occurred on the direct debit.
Production implementation date: 3rd September 2024
Webhook Admin Screen Updates
Webhook Search
You can now search for webhooks directly in the Pay Advantage dashboard. Filters are available for all webhook types, and you can also search by code to easily locate specific events.
Webhook Resend
Setting up webhooks can be challenging, and sometimes you may miss a specific type or encounter a failure. To address this, we've introduced a webhook resending feature. You can now select webhooks you'd like to resend, and they will revert to a sending state until you've successfully acknowledged their receipt.
PayTo (Beta)
PayTo is a new payment method that enables instant bank account transfers, providing immediate feedback on whether the transaction was successful. It’s protected from chargebacks, offering a secure alternative to traditional payment methods. PayTo is now available in the Pay Advantage dashboard and is also supported in the iFrame, Payment Requests, and Payment Authorization API endpoint.
How to use PayTo
iFrame and Payment Requests: Simply add "PayTo" as a payment option to make it available for customers to select.
Payment Authorization API: When issuing a payment via the API, you'll receive a pending status initially. PayTo statuses are communicated through webhooks, and within a minute or less, you’ll receive a webhook indicating whether the payment was successful. This process is designed to mirror the familiar workflow of credit card transactions via the API.
We are introducing a webhook management screen that allows you to view and check the status of your created webhooks. This feature is particularly useful if you have stopped receiving webhooks and need to diagnose the issue independently. You can access this screen through the developer portal.
The screen is divided into two sections:
1. Webhook registration
To register your webhooks, enter the URL where you want to receive them. You will be prompted to record the secret key needed for signing the payload. Implement this key into your webhook code, then click the re-arm button to initiate the validation process. If any step fails, the system will indicate the exact point of failure, allowing you to correct the issue and click the re-arm button again. Repeat this process until your webhook is fully registered.
2. Webhook logs
You can now view all the webhooks sent to your server, which is very helpful for understanding payloads and diagnosing issues if a webhook wasn't processed correctly. In the near future, there will be an option to resend webhooks, allowing you to replay events for testing and troubleshooting purposes.
Chargebacks - Are no longer failed payments
❗️
Important - Breaking change
To accommodate the introduction of partially charged-back payments, we have updated the way chargebacks are handled and reported in Pay Advantage. These changes will soon be available in the sandbox environment, and we require all API merchants to test their code in this environment to ensure compatibility with the new system. Please note that chargebacks may not always be for the full payment amount.
A new refund webhook will provide the following information. Understanding the type of refund is crucial, as it will indicate whether the refund was initiated by a refund request or due to a chargeback.
The example webhook below shows a refund of type "chargeback" and includes details about the chargeback amount and the payment code associated with the chargeback. Similar webhooks will be received for regular refunds, but their type will be "refund".
Please note: Once this change goes live, any chargeback previously marked as failed will no longer be considered a failed payment. Instead, it will be classified as a payment with an associated chargeback.
A newly introduced webhook has been release where you are able to be notified by webhook about any refund updates or chargebacks. Most payments are refunded by the merchant however, there are circumstances where we refund payments due to fraud or other reasons. When a refund occurs you can now handle these scenarios in your backend system by handling these webhook events.
The differentiating parameter is Data.Type. This will provide the information necessary for understanding if the money has been given back to the customer via a refund or via a chargeback.
Both refunds and chargebacks are not required to be the full amount of a payment. You may see multiple refunds or chargebacks come through for a single payment. Ensure that your system is able to handle this information. External ID is a handle parameter to use to be able to link the refunds and the payments or chargebacks together.
If you were previously calling the api /payments_failed/ to retrieve chargedback payments and you will now be able to call the payments API to return all payments with chargebacks. The type parameter will be used to
ALL CHARGEBACKS - https://api.payadvantage.com.au/payments?amountchargedbackfrom=1
ALL REFUNDS - https://api.payadvantage.com.au/payments?amountrefundedfrom=1
OR
ALL CHARGEBACKS - https://api.payadvantage.com.au/refunds?type=chargeback
ALL REFUNDS - https://api.payadvantage.com.au/refunds?type=refund
What do I need to do?
Handle the new refund type webhooks. You are welcome to ignore these new events if they are not important to your system. However, you will need to ensure the new refund webhooks do not cause failures in your current system
If you are relying on failed payment webhooks to notify of chargebacks, you will need to change it to listening for the refund webhook. Then monitoring the data payload to determine the type of the refund. It will either be refund or chargeback. To test chargebacks in our Test/Sandbox environment follow the process outlined here: https://docs.payadvantage.com.au/docs/charge-credit-cards-in-sandbox#simulate-chargeback
If you were calling the /payments/ or /payments_failed/ API to understand what payments had been chargedback you can now call the /payments?amountchargedbackfrom=1 to return all chargebacks.
This is currently available for testing in the sandbox environment
Previously, our webhook implementation required API users to make subsequent calls to the Pay Advantage API to obtain additional data about the received webhook. However, we've improved this experience by directly providing the payload that would typically be acquired through such API calls. This enhancement significantly reduces the need for extensive developer coding and enables immediate action upon receiving the webhook.
If you prefer not to include the webhook payload data in your webhook, we can ensure that you are excluded from the latest webhook update.
We've simplified the process of associating a DDR with a payment. With the newly introduced feature enabling search by ddr.code in the GET /payments endpoint and the inclusion of ddr.code within the payment record itself, linking payments to specific DDRs has become effortless. Now, you can seamlessly identify which payments correspond to which DDRs, streamlining your workflow.
Search payments using DDR Code
curl --request GET --url
'https://api.test.payadvantage.com.au/v3/payments?ddr.code=AAAAAA'
--header 'accept: application/json'
Previously, our webhook implementation required API users to make subsequent calls to the Pay Advantage API to obtain additional data about the received webhook. However, we've improved this experience by directly providing the payload that would typically be acquired through such API calls. This enhancement significantly reduces the need for extensive developer coding and enables immediate action upon receiving the webhook.
If you prefer not to include the webhook payload data in your webhook, we can ensure that you are excluded from the latest webhook update.
The introduction of Apple and Google pay has added two new payment types. These payment types will be returned from the GET /payments API call and the paymentType will be either "google_pay" or "apple_pay".
To adapt to the recent updates, please consult the documentation that details the new events: device-complete and device-error. These events are triggered when a user selects the Apple Pay or Google Pay option, bypassing the need to enter credit card details, and thus, eliminating the necessity for calling the iFrame authorization. https://docs.payadvantage.com.au/docs/apple-google-payments
