January 2024

In January 2024 we updated the idempotency page, added info about reactivating cards, added new events to support installment loans and updated some event fields, updated the lost/stolen guide, added new status codes for the Loan API, clarified card activation, reorganized the RDFs and fixed information about Mastercard merchant credits. Click January 2024 to see the details.

Idempotency update

We have updated the Idempotency page for the Program API to be more specific about how each endpoint handles duplicate-transaction checks. Not all endpoints check for duplicates, and not all use transactionId for idempotency.

Reactivating card

We added a section to the Setting Up a Card Program guide to explain how to reactivate cards that are in a non-active status.

Event updates

We added these new event messages to support installment loans:

• loan_creation_event — A loan has been successfully created for a customer.
• loan_creation_failure_event — An incoming loan creation request has failed.
• loan_payoff_event — An incoming payment request made by a customer results in the payoff of the loan.

We also made these changes to event messages:

• BPCC: billpay_check_cleared — A new field was added and an existing field was changed:
  • cleared_date — A new field that contains the date the check cleared.
  • proc_date — This formerly said that it was the check-clearing date. It now says that it's the date the billpay transaction was initiated.
• BNSF: denied_auth_nsf — The description for the amount field said it was signed, but it is actually not signed.

Revised lost/stolen procedure

We have refactored the Lost, Stolen, or Damaged Cards guide to provide more detail about the end-to-end process. We also created a separate section for Digital First cards. Furthermore, we added a page to detail the workflow for the new Replace Lost/Stolen Card endpoint.

New status codes for Loan API

We’ve added new status codes for the following endpoints in the Loan API:

Card activation clarification

We have clarified which procedures should be used to activate a new card, depending on the card type. Card activation in Setting Up a Card Program has the details.

RDF reorganization

We have reorganized the RDFs and CDFs and renamed the groupings:

• Base RDFs — Formerly the "Secondary RDFs," this is the standard RDF suite containing Customer Master, Account Cards, Authorized Transactions and Posted Transactions.
• Service RDFs — Formerly called CDFs, they contain data related to basic platform functions such as expired auths, settlement, and disputes.
• Product RDFs — Formerly called CDFs, these files contain data related to specific Galileo products such as overdraft, ACH, MSI installments, and fleet cards.
• Legacy Base RDFs — Formerly the standard RDF suite, these are the fixed-width files that contain only a subset of possible RDF fields. These legacy RDFs will eventually be deprecated in favor of the Base RDFs.

The filenames for individual RDFs have not changed. They are available over the same SFTP channels as before.

Mastercard merchant credit fixes

In the Mastercard Banknet (credit) merchant credit section of Card Transaction Examples, we corrected the description as follows:

• Merchant credits from the Mastercard (credit) network sometimes arrive in the authorization stream and other times arrive only in the settlement batch file. The previous version said that they did not arrive in the auth stream.
• When the merchant credit settles, Galileo sends only the BADJ: adj event message. The previous version said that SETL: setl was sent at the same time.