October 2023
In October 2023 we converted the ACH Early Access guide from a PDF into a public guide, added ANI support, automated secured credit limits, added an RDF and international character support, added more advanced Auth API fields, added a transaction ID guide, clarified merchant credits, added fields to an RDF, added Event API information, updated the Payment Risk Platform (PRP) guide, updated the Payment Screening for Tax Refunds guide, added fields to SETL, updated a couple of scenarios, updated transaction codes and a response code, and added advanced Auth API fields. Click October 2023 to see the details.
New(ish) guide
ACH Early Access is now available on the public docs site as a child page to ACH at Galileo.
ANI support
Galileo has added support for Account Name Inquiry (ANI), which can accompany an AVS check.
Automated secured credit limits
Galileo now updates the credit limit based on the funds in the secured account. Clients who have implemented Secured Credit prior to October 2023 continue to be responsible for updating the credit limit using the Set Credit Limit endpoint.
New RDF
We have added the Bad PAN Authorizations RDF, which contains a list of authorization requests from card numbers with your BIN, but the PAN does not exist in the Galileo system. This RDF can help you identify fraud attempts.
UPDATE: The instances of CDF in this entry were changed to RDF.
International character support
We updated the description of the message
and senderMessage
fields in Create Account Transfer to indicate that they support international characters.
More advanced Auth API fields
We can now parse these data elements and subfields to return in advanced_auth_api_fields
in the Auth API:
- DE007 — Transmission Date and Time
- DE055 — Integrated Circuit Card (ICC) System–Related Data
New guide
We created the Transaction IDs guide to consolidate information about how Galileo assigns transaction identifiers and how you can create unique identifiers for your own system. This guide does not contain new information but instead puts together information from various guides in one place.
Clarification on merchant credits
We updated the Merchant credits section of Crediting Cardholder Accounts to include the approval process for merchant credits, which affects the timing of when they are posted. We also removed statements that are no merchant credit requests from Mastercard Banknet (credit).
New fields in the B2B RDF
We added new fields to the B2B Customer Master Supplemental RDF:
PMT_REF_NO
AVAILABLE_BALANCE
RTF_CURRENT_BALANCE
UPDATE: The instances of CDF in this entry were changed to RDF.
Events API for ALCs
We've added a section in Designing Authorization Controls to show the ALC-specific messages that are included in DAUT: denied_auth
event messages.
PRP updated features
The Payment Risk Platform guide has been updated to reflect the latest changes to the product and provide an accurate list of supported features.
Payment Screening changes
The Payment Screening guide has a new title: Payment Screening for Incoming ACH Credits, to reflect the latest changes to this feature.
New SETL fields
We added several optional fields to the SETL: setl
event:
atm_fee
— Amount of the ATM fee, if any- Domestic Mexican transactions only:
usd_amt
— The amount of the settlement in U.S. dollarsrate_value
— The exchange rate that was used to calculate theusd_amt
rate_date
— The date/time whenusd_amt
was calculatedrate_id
— Identifier forrate_value
Updated card transaction scenario
We updated Scenario 9: Merchant Credit (Mastercard Banknet) to show a merchant credit arriving in the authorization stream before being processed as an adjustment. The previous version showed a merchant credit arriving directly in the batch settlement file without involving the authorization stream (although that path is still possible).
Updates to transaction codes
We added AUP
(preauthorization fully completed), AUZ
(merchant credit) and AUW
(cash withdrawal) to the Authorization stream transaction codes table for Mastercard credit.
Updated response code
We added response code 11
to the Authorization Response Codes enumeration. This code is not returned to merchants but instead is present in the AUTHORIZATION RESPONSE
field of the RDFs to indicate an authorization entry that is generated for a settlement that does not have a matching authorization.
More advanced Auth API fields
We can now parse these data elements and subfields to return in advanced_auth_api_fields
in the Auth API:
- DE012 — Local time at the POS
- DE013 — Local date
- DE048 Subelement 61 Subfields 1, 2 – Merchant support for partial authorizations and purchase-only approvals
Response code for force-posted transactions
We added AUTHORIZATION RESPONSE
to the Authorized Transactions RDF example in Scenario 16: Settlement Without Authorization to demonstrate that when an authorization is generated for a settlement without a matching authorization, it has a response code of 11.