Highlights from this release include new hosted payment form features, additional end-points for the Account Updater API, dynamic descriptor support for merchants using FIS, and a number of other minor enhancements and bug fixes.
To help merchants mitigate card testing fraud we are introducing a new auto-locking service for our hosted payment forms.
When configuring the feature our customer service team will be able to input a number of declines and a time (in seconds). This service will then keep track of the number of declined transactions a hosted payment form generates within a given amount of time. If the number of declines exceeds the acceptable number within the provided timeframe then the hosted payment form in question will be locked automatically. An email will be issued to the merchant with details on unlocking the form to continue processing.
We are continuing to make additions to our Account Updater API service. In this release, we have added a few new end-points that will be helpful for managing an account updater integration. You can review the full end-point definition here. Following are the highlights of the new functionality for these additional end-points.
On the initial release of the Account Updater API the
subscriptions end-point only supported requests for getting the details of a subscription. In this release, we are adding the POST method to this end-point. This will allow a request to add new token data to an existing subscription.
Similar to the above, the
subscriptions end-point only supported the GET HTTP method originally. With this release, we are also extending this end-point to include the DELETE HTTP method. This allows the deletion of an entire subscription or a specific card within the subscription.
In the first iteration of our API guide, the
subscriptionsend-point was shown as
subscription. You should see this change reflected in the API guide going forward.
Merchants utilizing FIS as their back-end processor now have the ability to configure a custom merchant descriptor when setting up or editing their card processor settings with the PayConex customer service team.
These new fields are labeled as:
- Merchant Descriptor: The descriptor the merchant would like to appear on customer statements. Limited 25 alphanumeric characters per FIS guidelines.
- Merchant Descriptor City: The city that the merchant would like to appear alongside the descriptor on customer statements. Required if using a merchant descriptor.
- Merchant Descriptor State: The state that the merchant would like to appear alongside the descriptor on customer statements. Required if using a merchant descriptor.
In this release, there are a few changes to the recurring billing user interface within PayConex. These changes are intended to help show more relevant information when viewing a recurring schedule and make the creation/editing of recurring schedules easier.
A few specific items that you will notice changing:
- When clicking to view a recurring schedule you will be presented with a bit more information about the recurring schedule.
- When editing a record, now the form for editing will appear below the details of the recurring schedule.
- When adding a new recurring schedule, or editing an existing schedule, and changing the payment data a button will be clicked that will present a modal where the card or ACH data can be modified.
custom_data or Custom Data element was not present when printing transaction details. We have added this as an element on the page with this release.
It was requested that we allow PayConex admin users the ability to modify the ACH Verification Permissions on their accounts. The service will still need to be enabled through a Bluefin representative, but afterward, merchants will be able to modify these settings as they would like.
You can read more about these settings and how to modify them in our article here.
It was reported that in some cases when PayConex was declining transactions because of an invalid AVS or CVV response the transaction actually completed processing at the back-end processor. In this release, we have included changes that should help prevent this from happening going forward.
Some authorizations created using EMV card input were having issues being captured properly. The issue discovered was that the entry mode was being overwritten improperly when issuing the capture to the back-end processor. This issue has been corrected.
In some cases, merchants using First Data RapidConnect processing reported that transactions were being declined by the processor because required 3DS data was not present in the transaction. This was occurring specifically in cases where our 3DS feature was disabled on the account. In this release, we have updated our request format to RapidConnect to help prevent this issue going forward.
In some instances when the manual settlement feature was utilized the settlement was taking longer to complete due to size. This was causing our API response to timeout sooner than expected. With this release, we are increasing the timeout for this to help prevent that issue in the future.
One limitation that FIS has in their processing is that the refund transaction type is not allowed after 45 days. After this time a credit transaction should be issued to the customer for refund purposes. PayConex will now check if the transaction being refunded is within 45 days or not, and send the appropriate transaction type. With this change, PayConex refunds will still appear as expected within our gateway and reporting. The back-end transaction type used is all that is being modified so that we can support refunds past the 45-day limitation by FIS.
There was an issue with how transaction amounts were stored that caused the PayConex ReportingService API to not be able to gather declined transactions. This issue has been corrected and going forward these transactions should appear, when applicable, in ReportingService API responses.