In May we added a new CST guide: Payment Posts & Returns, refund-check timing, supported RTF product-switching, updated an event name, changed some authorization response codes, added a lost/stolen tip, added SETL fields, updated freeze events, added a new event, specified TLS version, clarified AAAU, added a DSPC field, removed non-functional types, added a response field, added some trans codes, clarified roundup enablement, clarified a federal benefit endpoint, added a field to FACH, updated billpay events, added some endpoints, added a new event, published a new guide, added a new ACH return code, added new deposit category codes, improved the Modify Pending Deposit Status Return Codes enumeration, removed erroneous input params, changed a nullify property, fixed billpay endpoints, added address character support and finalized the Get Balance response field definitions. Click May 2023 to see the details.
Clients that use the CST can now ask their Galileo representative for the Payment Posts & Returns CST guide, which provides information and instructions for Payment Screening for Tax Refunds.
Refund check timing
To the Account Holder Refunds guide we added two data points:
- After issuing a refund check, it takes about 30 days for the account holder to receive it.
- If you place a stop payment on a refund check, the funds are returned to your refund account within 24–48 hours.
RTF product-switching support
Switching products for RTF funding accounts is now supported. For both RTF funding and RTF spending accounts, the product may be switched, but only to another product in the same product category, i.e., RTF funding product to RTF funding product, and RTF spending product to RTF spending product.
STPD event name
We updated the event name for the STPD event to
denied_auth_stip. This is a change to the reference, not a change to the event.
Mastercard and STAR response codes
Mastercard and STAR have changed some of their authorization response codes. Check with Galileo to see if your program is using these new codes yet.
|Condition||New response code|
|Frozen cards||62 — Mastercard and STAR. Frozen card|
|CVV2 failure||63 — Mastercard only. Security violation|
To the Lost, Stolen, or Damaged Cards guide we added information about how to use the
CSNT: card_status_change event message to retrieve the PAN and/or CAD of the replacement card within minutes of reporting a card lost or stolen.
New SETL fields
pds0180 as optional fields for the
SETL: setl event.
New frozen-card event information
The freeze-related events have been updated:
FRZN: frozenhas a new field
freeze_end_date, which contains the date when the freeze will expire.
UNFZ: unfrozendescription clarifies that the event is not sent when a freeze expires.
We added the
ACFC: account_feature_change event, which is triggered when account feature 20, 21 or 22 is changed.
TLS version clarification
We clarified that Galileo supports TLS version 1.2.
Clarity on auth event
We clarified that the
act_type field of the
AAAU: auth message is not included when there is no dollar amount.
DSPC field added
We added the
dispute_pc_amount field to the
DSPC: dispute_pc event.
Simulated transaction types removed
From the Simulated Transaction Types enumeration we removed the
transTypes that are not yet fully functional. Those types that do work are represented in the Simulating Card Transactions guide.
New response field
customer object in the response to Get Account Cards we added
Card load trans codes
We added the STAR card load trans codes to the Transaction Types enumeration.
We clarified that the Set Roundup Accounts endpoint does not activate roundup for the specified account (it only defines the account); instead, you must use Set Account Feature
type: 11 to activate it.
Clarification on Federal Benefits endpoint
We clarified that when using the Create Federal Benefit Enrollment endpoint, it automatically creates a secondary account for benefits deposits that shares its balance with the primary account.
New FACH field
We added the
ach_trans_id field to the
FACH: ach_credit_return event.
Updated billpay events
We updated the descriptions for the billpay-related events to include triggers and processes. These are the updated events:
We added three endpoints to the Reference:
- Delete Account-Level Auth Control
- Delete Account-Level MCC Control
- Delete Account-Level Merchant Control
We added the
BRRJ: billpay_rejected event to the Reference.
We published the Payment Screening for Tax Refunds guide.
New deposit category codes
The Modify Pending Deposit Status endpoint has new deposit category values, as shown in the new Deposit Category Codes enumeration:
NAM– Incoming ACH deposits from new originators are sent to manual review for name matching.
RNM– Receiver name mismatch for tax refunds
Improved enumeration guide
We updated the Modify Pending Deposit Status Return Codes enumeration to include more information on what the codes mean and how to handle them. We also added the new
R17 return code.
Erroneous input parameters
We removed erroneous input parameters from the Modify Pending Deposit Status description:
webPwd. These parameters were never supported by the endpoint—they were mistakenly present in the reference.
address2 as a nullable parameter for the Update Account endpoint. This removal does not represent a code change but rather aligns the documentation with the endpoint's existing functionality.
We made a few fixes for billpay-related endpoints:
- In the guides we explain that when calling Search Biller Directory, you should pass the
billerStateto help narrow options when billers have the same name.
- We removed "required" from these Get Billers response fields:
- We removed a link to the pagination instructions from the Get Bill Payment History endpoint.
Address line character support
In address lines 2–5 for enrollment endpoints such as Create Account, we have included a link to the supported character sets.
Get Balance refinement
After extensive research, we have further refined the definitions of the Get Balance response fields to account for these facts:
- A billpay transaction is pending only until the amount has been adjusted out of the account, which happens 1–30 minutes after its creation. A billpay transaction is therefore present in
pending_billpayonly for that short time.
- The only difference between
pending_billpayis subtracted from
balancebut not from
balance_without_pending. Therefore, if your program does not use Galileo's billpay function, or if a customer does not use billpay, those two values are always the same.