Unfortunately, on April 18, 2024, we implemented a change in our handling of payments via ePay before providing the necessary notice to both organizations and integrators, for which we deeply apologize.
In mid-April, we bundled tasks together between two major development projects to fix minor errors and optimize various parts of our system landscape. Unfortunately, the aforementioned change in handling ePay was included without the necessary understanding of the implications for accounting, which we acknowledge is inconvenient and should have been caught.
You can find a brief description of the release in our Release Notes: https://feedback.onlinefundraising.dk/announcements/holtasoley-11-release-notes
The change is related to our handling of payment gateways, where we provide the given gateway with a unique order number, resulting in a unique transaction number after payment completion. This ensures that the money matches during queries and settlements. During support tasks in 2023, we discovered that we were registering both our order number and ePay's transaction number as the transaction number, reducing our ability to control queries and settlements. This was what we aimed to fix.
We apologize for the inconvenience this has caused and are available for further clarification.
We are also working on a more robust setup to make integrators and other significant stakeholders aware of such changes.
Best regards,
Stephan
Detailed example of the problem that was solved
For the vast majority of payments, queries and settlements match, but support tasks revealed that ePay could complete two transactions on one order in at least one scenario, which we could not identify.
The scenario is as follows
A person sees a post on social media via a smartphone and is motivated to donate by clicking on the post's link. The link opens in the social media's internal browser, where a form is filled out and leads the person to ePay's payment window. The person is then asked to validate with Strong Customer Authentication (SCA) via an external app like MitID or MobilePay. The payment is completed, regardless of whether the person returns to the social media.
The problem arises if the person returns to the social media more than 24 hours later, reopening the internal browser and refreshing the payment session, which leads to ePay's payment window with the same order number as before. If the payment is completed again, ePay records two transactions related to one so-called order in OnlineFundraising. ePay normally prevents this, but only within the first 24 hours, so the scenario is significantly limited but real.
There are other ways to prevent this scenario, but our first challenge was our inability to identify the extent, which was the approach to the change that, as mentioned, affects established workflows in accounting.
Insight into data
Both OnlineFundraising's order number and ePay's transaction number can be found via Payment through API, as well as our export module, expressed as follows:
{
"paymentGuid": "a863d62e-d53b-4651-9b7b-xxxxxxxxxxxx",
"...": "...",
"paymentMethodType": "Card",
"paymentGatewayProvider": "ePay",
"paymentGatewayReferenceId": "751ed606-c489-4e8c-93e7-xxxxxxxxxxxx",
"paymentGatewayTransactionId": "372939754", // ePay Transaction ID (previously OF Order ID)
"metaData": {
"card": {
"type": "Dankort",
"cardNumber": "457150XXXXXX7478",
"acquirer": "Nets/Teller",
"orderId": "421606428", // OnlineFundraising Order ID
"transactionId": "372939754" // ePay Transaction ID
}
}
}