This release is highlighted by our initial rollout to allow PayConex to accept Apple and Google pay along with adding support for Real-time ACH Account verification.
We are very excited to announce that PayConex now supports Apple Pay & Google Pay Web transactions through the API. At Bluefin, we are committed to offering faster, easier, secure, and more convenient ways for our merchants to receive payment.
Adding the Apple Pay & Google Pay button to your checkout will increase conversion and provide consumers with a secure, fast checkout experience.
We now support Real-Time ACH Verification for the merchants to comply with the new NACHA Mandate. Click here to know more about the rule.
We have partnered with Microbilt, they are a pioneer in consumer data and a NACHA preferred partner. Our offering is unique and is built such that we let merchants decide their ACH verification rules. We encourage you to reach out to our team to learn more regarding this offering.
Merchants processing on the FIS platform with an industry type of e-commerce or mail/telephone orders can now take advantage of the additional_fee parameter.
The fee will display as part of transaction details & can also be added to the custom report. Merchants that have API integrations can also include this parameter when using Reporting Service API.
For merchants using PayConex APIs, we have updated the QSAPI response to include ShieldConex tokens. By supplying the token data back within the response, the client can now go directly to ShieldConex to detokenize that data in the future.
We had an issue wherein if the Agent account was set up in a certain timezone was causing some inconsistencies in transaction time on Transaction History pages and Transaction Detail. This issue has been resolved.
We had a regression where the configuration was allowing payment pages to be accessible even when the feature was disabled. This has been corrected so that hosted payment pages will not be accessible if the feature is turned off.
When using the POSTback feature there was a situation where the content-type header was not being set to the same format as the body of the POST. This has been resolved.