Changelog
EZYPAYHOW EZYPAY WORKSPARTNERS

Ability to Edit Subsciptions

Ezypay would like to introduce two new features to make it easier to change customer subscriptions.

Currently, a customer's subscription cannot be edited. If any changes are required, a merchant has to cancel the subscription for a customer and then restart a new one.

Now we have released features that allow you to make changes within an existing subscription without having to cancel it and restart.

Editing Subscriptions that end after the Total Amount is Collected (TAC Subscriptions)

Release Date1st October 2021
Purpose of the New FeatureMerchants will now be able to update the regular recurring amounts or the end total amount to be collected in a subscription. Payments will be calculated automatically and cease when the TAC amount has been collected.

Any changes made to these subscriptions will be applied immediately and can only be applied to subscriptions that have an active, past due (due to a failed payment), pending, or future status.
Link to Relevant Documentationhttps://developer.ezypay.com/reference/update-subscription

Editing Subscriptions that are Ongoing

Release Date1st October 2021
Purpose of the New FeatureMerchants will now be able to make the following changes against a subscription:
- Changes to the regular recurring amount of a subscription.
- Changes to the end date of a subscription.
- Changes to the accounting code for a subscription.
- Changes to the recurring billing date for a subscription within the same billing cycle. For example, for customers on weekly or fortnightly payments, a merchant may wish to change the day of the week that the customer is billing. For customers on monthly payments, a merchant may wish to change the date of month the customer is billing.
Link to Relevant Documentationhttps://developer.ezypay.com/reference/update-subscription

📘

Any changes made to these subscriptions will be applied immediately and can only be applied the subscriptions that have an active, past due (due to a failed payment), pending, or future status.

All changes made against a subscription will override any individual future invoice updates that had been scheduled previously.

Improvements to the Checkout Page

Ezypay has made 3 improvements to increase the security of our checkout page. See below for a more detailed explanation on what these improvements are.

Release Date20th September 2021
Improvements MadeThere will be 3 main changes to the current behaviour:
1. A checkout ID will be automatically invalidated after a successful payment. This checkout ID will be invalidated and will no longer be used.
2. Each checkout ID will now be automatically invalidated and cannot be reused after 3 failed attempts.
3. Integrators will be able to use the API endpoint to disable a checkout session after it has been created.
Current BehaviourThe current behaviour of the checkout page is that:

A single checkout session can be reused repeatedly regardless of whether there were multiple successful or failed payments for a Checkout ID
 A single checkout session can also be reused for multiple customers.
* There was no functionality to disable a checkout ID after its creation.
Link to Relevant DocumentationDocumentation to API Reference Guide
https://developer.ezypay.com/reference/disable-a-checkout-session

Modifications to the Settlement Tax Invoice

Ezypay has redesigned the existing Settlement Tax Invoice. These changes ensure that Ezypay's Settlement Tax Invoice is compliant across each of the countries in which we operate, along with offering an improved design for auditing purposes.

The new format will be effective from 19th February 2021. Any Settlement Tax Invoices that are generated for any time prior to Wednesday 19th February 2021 will be displayed in the old design format.
Invoices generated for any time after this will be displayed in the new format.

New Format Effective From19th February 2021
New Changes There is no change to how the invoices are issued.
The layout of the invoice has changed to improve how the data is displayed.
New columns have been added with streamlined information along with other visual enhancements.
Link to Relevant Documentation Guide for Australia and New Zealand:
www.ezypay.com/settlement-tax-invoice-guide-anz

Guide for Asia:
www.ezypay.com/settlement-tax-invoice-guide-asia

Important Notes

Fee charges issued in invoices before March 2020If payment for invoices issued before March 2020 have been collected after 19th February 2021, then the merchant paid fees will not be displayed on the tax invoice. For example, if payment for an invoice issued in February 2020 was only collected in March 2021, the merchant paid transaction fee will not be displayed in March's tax invoice. Upon request, Ezypay can provide you a revised tax invoice to account for the missing fee(s) if this occurs.
Reallocation of customer paid fees before August 2020If any customer paid fees were reallocated to the merchant for invoices refunded, written off, marked as paid or were the result of a chargeback before August 2020, they will not be displayed in the new design. Upon request, Ezypay can provide you a revised tax invoice to account for the missing fee(s) if this occurs.

Maximum Debit Value On Invoices

This change is an important part of Ezypay's overall Fraud & Compliance activities. Previously, we relied upon transaction monitoring to alert us to transactions above the allowed limits (after the fact). Given the evolving complexities and volume of the transactions on our platform, it is critical we prevent these transactions from occurring.

We do not foresee any impact on your current integration, but please ensure that you provide the validation message to the merchant so that a lower amount can be entered and retried.

This change is implemented for both our sandbox and production environments.

Release Date 1st September 2020
New Changes We have updated the Create Invoice API (Ad-Hoc) and Checkout Pages to add extra validation to the AMOUNT field to check against a merchant's Maximum Debit Value (MDV).

These updates apply to all regions for all ad-hoc created invoices and Checkout Page transactions (note that this does not yet apply to subscription payments).

Attempted invoices that are greater than a merchant's Maximum Debit Value will be rejected. You will receive an HTTP error 400 if the total invoice amount is over the configured Maximum Debit Value.

The payload message of the validation error will be as follows:

"type": "invalid_request_error",

"code": "invoice_exceeds_merchant_maximum_debit_value",

"message": "Total invoice amount (excluding Ezypay fees) exceeds this merchant's maximum debit value. Please retry with a lower amount"

The message needs to be visible to the merchants, to allow merchants the chance to change the invoice amount before proceeding to create a new invoice. For our Checkout Pages, the validation message will be displayed on the Checkout Page and the customer will not be able to proceed with the transaction.
Link to Relevant Documentationhttps://developer.ezypay.com/reference#create-an-invoice

Checkout Page

Ezypay has developed a Checkout Page and its ready for you to implement. This new feature allows merchants to take once-off credit card payments via a unique checkout URL.

Ezypay has been gathering feedback for some time from our partners and merchants on the importance of a once-off payments feature. While Ezypay continues to primarily focus on subscription and recurring payments, we recognise the need for once-off payments to complete an integrated payments experience. We’re certain this feature release will positively impact the integration with your software and provide useful benefits to your users.

Release Date 11th September 2020
Purpose of the New Feature The Checkout Page provides an immediate payment status for once-off credit card payments.

This feature allows you to take payments via Ezypay’s platform for items that are different from the customer’s regular schedule e.g. purchasing individual items like a drink or towel, or for collecting any outstanding fees or single charges
Link to Relevant Documentation For details on the payment workflow and how to integrate these checkout pages into your application:
https://developer.ezypay.com/docs/checkout-page

For the API reference guide on how to implement this feature:
https://developer.ezypay.com/reference#create-a-checkout-session

System Maintenance on March 3rd

We would like to inform you that we will be performing maintenance to improve the infrastructure and stability of the Ezypay platform.

This will result in disrupted services within a 1-hour system outage window Tuesday, March 3rd, between the following times:

📘

Universal Coordinated Time (UTC):
Monday, March 2nd at 7:30pm to 8:30pm

Australian Eastern Daylight Time (AEDT):
Tuesday, March 3rd at 6:30am to 7:30am

New Zealand Daylight Time (NZDT):
Tuesday, March 3rd at 8:30am to 9:30am

Kuala Lumpur Time (UTC +8):
Tuesday, March 3rd at 3:30am to 4:30am

All of Ezypay’s online services will be affected during this period. This includes our hosted payment pages, checkout pages and our failed payment collection pages (paynow.ezypay.com).

Any attempts to add, edit or make payments during this time will return an error. You should re-try these actions after our system is back online. Payments that were already scheduled before the outage time will not be affected and will be processed as normal.

All API calls to api-global.ezypay.com during this time will receive a HTTP 503 response. You will need to retry these calls after our system is back online.

For up-to-date status for our system please visit http://status.ezypay.com. If you experience any issues after the outage period, please contact us at [email protected].

We apologise for any inconvenience this may cause.

Kind regards,
Ezypay Customer Service

Changes to how failed payments will be handled

At 12:30 pm AEST ( 2:30pm GMT) Monday January 13th, 2020, we will be updating the mapping of the payment provider responses to our failed payment response codes to provide more detailed and meaningful failed payment reason codes.

We will also be introducing a new process for invalidating payment methods. Ezypay will now act to automatically invalidate the payment method mapped to certain failed payment reasons. Invoices linked to a payment token that has now been invalidated can no longer be processed or retried.

To help you understand and interpret the correct failed payment responses, we are updating and making changes to our invoice, payment API and PAST_DUE webhook events. New data fields will be available in our sandbox environment to test.

How to handle failed payment responses from Ezypay

To ensure failed payments are correctly handled, the following workflow should be followed:

Obtain the status of the invoice from the Get Invoice API or from the Past due webhook.

  1. Ensure you read the failedPaymentReason code / description field to determine the type of failure reason.
  2. Ensure that you read the field paymentMethodInvalid so that you can store the payment method status to ensure that you receive the right information regarding the validity of the payment token.
  3. Ensure you subscribe to the webhook events invoice_past_due and payment_method_invalid
  4. The following new data objects in our API will make it easier for you to know the reason for the failed payment and will now be included in the invoice API.
  • paymentMethodInvalid
  • manualRetryPossible
  • failedPaymentReason (code, description).
  • paymentProviderResponse (code, description)

More detailed information regarding the API enhancements can be found https://developer.ezypay.com/docs/get-invoice-api-enhancements-invalid-payment-method-token-and-failed-reason-response-details

The new failedpaymentresponse codes and how they map to the validity of a payment token is summarised below, these codes and statuses are available from the Invoice API and also PAST_DUE webhook event.

Details on the invoice_past_due webhook data payload can be found here.
https://developer.ezypay.com/docs/webhook-event-response

You should ensure that these fields and mappings are understood in your integration.
Payment provider response codes and descriptions are also updated and the full list can be found here.

developer.ezypay.comdeveloper.ezypay.com
Failed Payment Response Guide

Invalidating payment methods

If any new invoice or invoice retry has an invalid payment method, these attempts will now receive a HTTP 413 response and as such, will not be received and, hence, not processed.

Please ensure that you subscribe to the payment_method_invalid webhook event. Details on the payment_method_invalid webhook data payload can also be found here. https://developer.ezypay.com/docs/webhook-event-response

Detailed information on invalidating payment methods can also be found here.
https://developer.ezypay.com/docs/failed-payment-handling-improvements

Any invalidated payment method that is linked to a subscription will result in its next recurring invoice not being delivered for payment processing. The payment_method_invalid webhook will provide a list of impacted subscriptions linked to the invalid payment method. You can easily make an API call to replace the invalidated payment method with a new valid payment method for the customer and all linked invoices and subscriptions will be updated. The subscription API will now also provide additional data to inform you if the payment method linked to it has been invalidated or not.

🚧

All of the above changes are available in the Sandbox environment. Please ensure that you have made the necessary changes and have tested your integrations here prior to 13th January.

📘

If you have any questions about these changes and the system behaviours that result, please do not hesitate to contact our Implementations Team on 1300 300 553 or at [email protected].

Modification to the Create Invoice API

Changes to the 'Create Invoice API'
Ezypay is making changes to the 'Create Invoice API". When creating invoices, you are now required to indicate if the payment is a one-off payment or a recurring payment.

This change is to allow for future improvements to how we handle and process transactions, there is no specific action for you to make any changes.

By default, all invoices created via the On-Demand API will be set to recurring.

Purpose of the New Feature This is to ensure that Ezypay can identify if a transaction is a recurring or one-off.

With this change there will be an additional flag available to Merchants/Partners when they submit on-demand invoices. This will be assigned to an invoice to either say "recurring" or "cardonfile".
By default all invoices created via the On-Demand API will be set to recurring.
All on-demand invoices created via the Hosted Payment Page will be set to “cardonfile” as default.
This information will be transmitted to Ezypay with the values being "recurring" or "cardonfile".
Current Behaviour Currently there is no flag assigned to recurring transactions for Merchants/Partners when they submit an on-demand invoice. Therefore there is no way for Ezypay to identify if a transaction is recurring or one-off.
Actions Required When merchants or partners create an on-demand invoice that is only for one-off payments, merchants/partners need to be advised that they need to set the processingModel flag to "cardonfile"
Note: By default, all invoices created via the On-Demand API will be set to recurring.

Merchants Transaction List Report

Previously merchants did not have have any form of reports that provided them information on the transactions that had occurred against their accounts to show whether the transactions were successful or if they had failed. Especially in the case of a merchant having insufficient funds for a settlement, as no Settlement Report would be available to them to understand why they had no settlement.

With the release of the Merchants Transactions List, all merchants would be able to generate this report in CSV format, which will provide them with a snapshot of data (transactions that had occurred and status) based on the specified date range.

This new report provides transparency and visibility to merchants on each transaction that occurs in their Ezypay wallet account upon it happening. With this information, merchants can start reconciling their data without waiting for settlement reports.

Release Date 14th November 2019
Purpose of the New Feature Merchants will be able to generate this report to gain visibility of all transactions that occurs in their Ezypay settlement account upon it happening. A user can set the time frame of the report to allow merchants to see what has been collected or processed within that period.

This details of the report:
This report is available in CSV format.
 A user will need to specify the date range for data retrieval.
Report provides data as of the date and time the report was generated.
 Report lists data in chronological order from when transactions occurred.
Report will list all transactions that has taken within the specified time period against the merchant's account. This includes customer payments, partner payments and any settlement adjustments made by Ezypay.
Useful Tips:
 Transaction holding period does not apply in the report. Merchants who wish to self-calculate the upcoming settlement amount will need to take into consideration the 3-day holding period applied on payment collections from customers. For a quick estimation of upcoming settlement amount, it is advisable to call the API to retreive collected next settlement amount
(https://developer.ezypay.com/reference#retrieve-collected-next-settlement-amount).
Failed payments, especially bank failed transactions, may only be captured on the report on a later date. Do not assume that a customer payment listed on the report is successful as the
bank may only inform Ezypay that the transaction has failed 1-3 business days later.
 Currently there is no auto email function for this report.
Current Behaviour Currently there is no report for merchants to access information that will account for transactions that had occurred (successful or failed). Especially for merchants who do not receive a settlement report because they did not receive any settlement.
Actions Required Integrating partners need to integrate with the API call listed below to retrieve the report.
Link to Relevant Documentation You can now call the new API end point https://developer.ezypay.com/reference#generate-merchant-transactions-report
to retrieve an Merchant Transactions List Report in CSV format.

Changes to the Reporting of Customer Paid Fees

Reporting on customer paid fees

Release Date: 20th November, 2019

Ezypay will be removing the reporting of customer paid Ezypay fees from both the settlement reports (PDF and CSV) and the settlement tax invoice (PDF). We’ve made this change to provide you with a simplified user experience if your Ezypay fees are mostly customer paid.

Customer paid Ezypay fees may consist of transaction fees, load fees and/or failed payment fees and are neither revenue to the merchant nor a payment made by the merchant to Ezypay.

With this change, you will no longer see these entries in the settlement reports and customer paid fees will not be included in the calculation of the settlement tax invoice issued by Ezypay.

User Guides

developer.ezypay.comdeveloper.ezypay.com
Settlement Reports