PayConex - 05.28.2024

This month's PayConex release introduces Level 3 Profiles within PayConex, a new source parameter for transaction reporting, accessiBe Widget integration, along with along with updates, improvements, and bug fixes. These include improvements to merchant initiated transactions and recurring processing efficiency as well as updates to the AVS decline workflow and our ACH transaction retention policy.

New Features

Level III Processing Profiles

The PayConex team is excited to announce merchants processing with FIS Express now have the ability to create Level III Processing Profiles.

These profile configurations allow a merchant to specify level 3 data elements that will be automatically populated at the time a transaction is processed.

You can see more in-depth details about this feature in our new guide on Using Level 3 Processing Profiles.

New Source Parameter for Transaction Reporting

In this release we are adding a new parameter for transaction reporting called source. This parameter will reflect from what source the transaction was originated from. Be it an API request, hosted payment form, virtual terminal, or other mechanism.

This new field will be accessible on transaction details pages (shown to the right), custom reports, and ReportingService API requests.

To have the field returned with ReportingService API requests navigate to SETTINGS > MANAGE SETTINGS in PayConex and select "Yes" for the "INCLUDE TRANSACTION SOURCE" option.

This field can also be selected for any custom reports by selecting it from the list of standard data fields to be included in the report.

accessiBe Integration for Enhanced Accessibility

To increase the accessibility for all users of PayConex we have integrated accessiBe's accessWidget as part of the user interface.

This service allows users to select an accessibility profile, and make other content adjustments, to provide a better user experience for their specific needs.

The widget icon is displayed on the bottom right of PayConex and when clicked a dashboard with a number of options related to accessibility is presented.


Card Brand Network Transaction ID for Reissue Transactions

Previously when processing tokenized (merchant initiated transactions) our system was not automatically applying the card brand network transaction ID. This identifier is supplied by the card brands and in some cases has became a required parameter for card-on-file transactions. This release is to insure current and future compliance with card brand rules regarding card-on-file transactions. There should be no impact to existing integrations or processing resulting from this update.

Improved Recurring Transaction Processing

The PayConex customer service team had some recent reports where recurring transactions were processed after the date they were scheduled. To help alleviate this issue and improve recurring processing our technology team evaluated our recurring processing engine and with this release have updated it to help increase reliability and speed when processing these transactions.

ACH Transaction Information Retention

NACHA rules state that ACH transaction records should be accessible for 24 months. In this release PayConex has been updated to retain that information for 24 months rather than the previous timeline of 18 months.

Bug Fixes

Fix Card on File Display for Updated Recurring Transactions

An issue was reported where the card on file for PayConex recurring transactions could be showing an incorrect last 4 if the card on file had been updated. This release corrects this issue.

Transaction Approved When AVS Declined

An issue was reported where a transaction that was designated as declined by the AVS checking system within PayConex was still processed/settled instead of being declined.

In many cases the response to an authorization from the card processor is an approval regardless of the AVS response code. The AVS decline feature on PayConex works by analyzing a transaction's AVS response code and presenting back a decline to the merchant if the AVS code received is on the merchant's disallowed list. As part of this process a reversal has to be done against the original authorization that was approved by the card processor.

The source of the reported issue was that the processor declined the authorization reversal. This is not a typical situation but is something that needs to be accounted for to prevent merchants from thinking a transaction was declined when it was actually approved and couldn't be reversed.

In this release we are making it so that these transactions will still appear as approved transactions in these cases.

  "transaction_id": "000000002274",
  "tender_type": "CARD",
  "transaction_timestamp": "2024-05-15 09:29:23",
  "card_brand": "VISA",
  "transaction_type": "SALE",
  "last4": "9990",
  "card_expiration": "1233",
  "authorization_code": "000039",
  "authorization_message": "APPROVED",
  "request_amount": 10,
  "transaction_amount": 10,
  "first_name": "test",
  "last_name": "tester",
  "keyed": true,
  "swiped": false,
  "entry_mode": "keyed",
  "transaction_approved": true,
  "avs_response": "Z",
  "currency": "USD",
  "error": false,
  "error_code": 0,
  "error_message": null,
  "error_msg": null