Asperato ONE application is being improved on a regular basis to ensure that our payment solutions meet customer expectations and any bugs are fixed as soon as possible. This page contains release notes and is updated by the team to give our customers visibility of any changes or improvements in each version. For latest package version please see our AppExchange listing here https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3A00000EcrOnUAJ


*** Version 2.14 (listed on AppExchange)

“Asperato refund user” permission set can now be used independently, without having to also apply the “Asperato standard user” permission set.

Upgrades from 2.10 & 2.11 no longer fail

Asperato permission sets work with the standard Salesforce user profile (after this Salesforce update: https://releasenotes.docs.salesforce.com/en-us/winter20/release-notes/rn_forcecom_custom_settings_access_cruc_addWinter.htm)

Payments no longer accept negative amounts

Payment schedules no longer accept zero or negative amounts

No longer possible to double-click on the “Process refund” button on the refund dialog (in both lightning and classic)

Repeat (batch) payments now explicitly fail if the “Payment route selected” does not match on both the payment & authorisation records

Documentation link fixed in Asperato setup page

“Customer ID” now consistently labelled


*** Version 2.13

PSP passthru parameters (https://asperato.github.io/userdocs/docs/psppassthrough).

FI parameters (6012 Merchant details) can now be supplied to Sagepay (via PSP passthru parameters) - https://asperato.github.io/userdocs/docs/fiparams

Description can be set for a GoCardless payment via PSP passthru parameters (https://asperato.github.io/userdocs/docs/psppassthrough).

Mandate & payment references can be set for GoCardless transactions (https://asperato.github.io/userdocs/docs/authorisations#custom-references).

Merchant group support - https://asperato.github.io/userdocs/docs/merchantgroups

Now possible to delete PSP connections from Salesforce.

Forte migrated to newer API (https://restdocs.forte.net/?version=latest).

Adyen API has been enabled (https://docs.adyen.com/api-explorer/). Currently this only supports Card payments.

Checkout.com API has been enabled (https://api-reference.checkout.com/). Currently this only supports card payments.

Multiple consecutive clicks on the "take payment using authorisation" button / dialog no longer result in multiple payments.

Multiple consecutive clicks on the "refund dialog" button no longer result in multiple refunds.

Note that version 2.13 is not supported by the FinancialForce-Asperato Integration package. Where applicable versions 2.11 and 2.14 onwards should be used.


*** Version 2.11

Add the option to setup an Asperato configuration and add / edit PSP connections in Salesforce classic (previously this was a lightning only feature.)

Fix a bug that could cause repeat payment amounts to be wrong by a penny in some scenarios.

Provide the ability to connect to a live Asperato configuration from within Salesforce classic.

In this version multi-merchant customers will not be able to edit PSP connections within Salesforce, therefore if you require sandbox connection a support case should be raised requesting assistance from Asperato team.


*** Version 2.10

Add the option to setup a configuration and setup PSP connections directly from Salesforce in lightning experience.

In this version multi-merchant customers will not be able to edit PSP connections within Salesforce, therefore if you require sandbox connection a support case should be raised requesting assistance from Asperato team.


*** Version 2.9

Add protection to the multi-merchant logic in the batch processes for a case where a payment record doesn't have a customer ID set.

Fix the display of the refund currency in the Lightning Refund component screen.

Remove the field level security checks from the postinstall script in case they cause issues during package installation.

Only update the Authorisation repeat reference fields if both are present to prevent the combination on the row being rendered invalid.

Send over the due date to Asperato in the repeat job rather than the payment date.  The payment date was never being initailised so the field was always null.


*** Version 2.8

Alter the batch repeat payment process so that it sets the 'Submitted for Processing' payment stage before the transfer of data to Asperato so that if two batch tasks overlap that there is no way that they can create multiple payment transactions for the same payment row.

Amend the logic for the future dated payment transactions so that it can't ever reset the payment stage back to 'Awaiting payment'.

Make the logic used to select Payment Schedules and Payments consistent.


*** Version 2.7

Update the eCommerce URL formulas to use hyperlink so that they display correctly in Lightning.

Alter the batch job selection SOQL so that it only picks up Payment rows that are connected to an Authorisation and that Authorisation doesn't have a status of 'Awaiting submission'.

Add a new stage to the Authorisation called 'Awaiting submission' and make that the default.

Amend the logic in the PutPaymentsServiceHandler class so that it uses the PSPreference as a way to determine which status to set rather than using dates, so as to avoid issues with time zones.

Add a new set of URL endpoint fields to Payment and Authorisation with much longer length and associated logic to use these first and fall back to the orginals if that is appropriate.

Mark the shorter URL endpoint fields as deprecated.


*** Version 2.6

Add the Error Code field to the AuthorisationSelector class.

Add the Error Code field to the PaymentSelector class.

Add the Error Code field to the RefundSelector class.

Change the class BatchProcessPaymentSchedules so that it only 'expires' Payment Schedule records in the past because the date field says 'last payment date', but that last payment wasn't being processed.

Add the field TransactionGroup (String) to both the putpayment web service and the Payment object - to be used to show where multiple payment records are part of the same overall transaction.

Add the field GiftCard (boolean) to both the putpayment web service and the Payment object - used to indicate that the record relates to a gift card payment.

Add the field Expired (boolean) to the getpayment web service - set true if the payment stage is anything other than 'Awaiting submission' or 'Failed'.

Add in string truncation to the payment and authorisation put handlers to stop potential insert/update errors when data is too long for the field to which it relates.

Fix the code in the postinstall script that creates the scheduled repeat payment job.

(Requires version 03 put and get classes in Asperato to use all the new fields (will still work with the old ones)).


*** Version 2.5

Fixed a fault with the batch repeat payments when in multi-currency mode introduced in version 2.01

Fixed a fault with the post install script to make sure it restarts the scheduled Apex task if it isn't running but has in the past


*** Version 2.4

ANYTHING EARLIER REQUIRES UNINSTALL/RE-INSTALL IN ORDER TO MOVE TO THIS VERSION. Please contact us for assistance.



Disclaimer: Whilst every effort is taken to ensure that upgraded packages are free of error, it is explicitly our clients responsibility to test all package upgrades thoroughly prior to implementing live. If any issues are found please contact suppor@asperato.com