Support Advisories

Monetra 8.18.1 has been released and is available for upgrade. This release contains Security fixes, and it is recommended that customers using Monetra payment processing upgrade to this version as soon as possible. 

Release Notes

Effective 8/25/2021

Monetra 8.18.1 has been released to the public and is a maintenance and security release.

This release is highly recommended for all users of Monetra and should be considered the most modern and stable release available.

Changelog

Security:

• [Medium] OpenSSL has been updated to 1.1.1k. This release addresses two security issues (CVE-2021-3711 and CVE-2021-3712), however only CVE-2021-3712 is applicable to Monetra. For more information please see: https://www.openssl.org/news/secadv/20210824.txt

Fixes:

• Chase Paymentech: Map new response codes as host issues to allow Standin
• NSF AutoDeny might not properly record reversals
• TOReversal with encrypted data should remove EMV tag 57 if it is masked data
• Global Payments: Fix reading and writing transid for card on file transactions

ThirdParty Library Updates:

• OpenSSL updated to 1.1.1l

____________________________

A previous version (8.18.0) was released earlier last month. Changes in this version will be included when you upgrade to version 8.18.1

Effective 8/2/2021

Monetra 8.18.0 has been released to the public and is a feature enhancement and security release.

This release is highly recommended for all users of Monetra and should be considered the most modern and stable release available.

Changelog

Database Schema: v4.14 (compatible with v4.0)

Security:

• [Medium] C-ares has been updated to 1.17.2. This release addresses a possible DNS spoofing attack that could be used by malicious servers.

Features:

• Partial Authorization behavior change. We have added a new feature we call NSF AutoDeny, along with a new msoft_code of NSFAUTODENY. It has long since been a requirement that merchants in card-present environments support partial authorization responses for credit cards in order to avoid fees for being out of compliance. The guidance was that if you couldn't support partial approvals that you needed to issue a reversal if you received one. Previously Monetra required merchants pass nsf=yes with transactions to comply with the requirements. Merchants that chose not to, might run into situations where issuers ignored the fact the merchant didn't support partial auths and send one back anyhow leading to unexpected funding for merchants. As of this change, any merchant that needs to support partial auths, if they do not pass nsf at all, or pass nsf=no, Monetra will send nsf=yes to the processor, then automatically reverse the charge if partially approved and return a decline with an msoft_code of NSFAUTODENY to the merchant. The fail-safe logic is in place for other card types and card not present environments, where if partial auths are not expected for the given situation, an automatic reversal will occur.
• The Payment Frame now supports acceptance of ACH payments.
• Proxy-Protocol support for inbound connections. The Proxy Protocol was developed by HAProxy but is also used by many other offerings such as load balancers offered by cloud hosting providers. The Proxy Protocol enables Layer 7 load balancing to preserve the original source ip of the client connecting to Monetra. To enable proxy protocol, configure a new port to be used by the load balancer in Monetra, and then add it to the COMM_proxy_protocol_ports setting in prefs.conf to tag that port. If a connection comes in to that port without using proxy-protocol, it will be rejected as invalid. It is required to still have ports that are not behind proxy protocol for things like the Monetra Installer, so new ports should be created instead of tagging existing ports as proxy-protocol.

Changes:

• Due to brand requirement differences with the new online refund policies, if a card present refund is attempted with an EMV card it is now downgraded to swiped. It is not recommended for merchants to perform card present refunds and instead reference the prior transaction by TTID to issue a refund.
• A new configuration parameter of always_output_phard_code in main.conf has been added. As of Monetra 8.17.0, phard_code will only be returned if the transaction goes online to the processor, which better matches with our documentation, however some integrations had coded to observed behavior instead of documented behavior and relied on phard_code even when it had no meaning for the given situation. This flag reverts to the prior behavior for these types of integrations. This flag will NOT exist with Monetra v9, integrators need to fix their solutions.

Integration Changes:

• The raw_cavv column, containing the 3D Secure Response Code, has been added to the gut, gl, and gft reports
• The descloc column, containing the Merchant Descriptor Location, has been added to the gut, gl, and gft reports.
• New msoft_code of NSFAUTODENY. Please see the NSF AutoDeny feature description above.
• The Payment Frame now permanently disables the Submit button after submission, even once a response is returned. If the submit button needs to be forcibly re-enabled, the parent page may do so via JS message called enableSubmitButton.
• The Payment Frame can be asked to render the ACH form by using the hmac-ach-enabled and hmac-ach-accounttype flags.
• Add a new merchant flag (merch_flags) named EMVODA_NONE_STANDIN_ALLOWED which instructs UniTerm to allow Stand-In authorizations even when EMV ODA was not performed. Use with caution as it means the card could not be validated, and could be a test card.

Fixes:

• Global Payments fixes for debt repayment, extended response codes, and long order number truncation
• The loopback simulator now properly checks for lodging data on refunds.
• Refund by TTID now imports lodging data into the refund so a merchant does not need to re-specify that data.
• Prevent installment payments where there is only one payment as this is not considered an installment under the brand rules. Merchants should use the recurring type and set the start and end dates to the same date when they want the transaction processed.
• The recurringlist query may fail on some databases due to missing quoting in the query.
• Fix a crash in recurringdel of customer records if the database chose to rollback under certain conditions.

ThirdParty Library Updates:

• SQLite 3.36.0
• c-ares 1.17.2