In August 2021 we added a Uses Cases section with a new guide, a transaction type, corrected an events field description, corrected some guides, added future scheduled payments, changed the format of some card-related fields, clarified a parameter description, added some new locales, updated a few other guides, added a new guide plus recipes, clarified some response field descriptions and added a status code. Click August 2021 to see the details.
New Use Cases guide section
We added a new Use Cases section (see About Use Cases) for high-level descriptions of Galileo programs and products. We’ve also added a new guide to this section, Business Banking Programs, an overview of Galileo’s solutions for your business customers.
New transaction type
In the list of Transaction Types, we added transaction type
7 (cash disbursement).
BEXP: auth_exp field description
BEXP: auth_expfield description
BEXP: auth_exp (authorization expiration) webhook, we corrected the description for the
open_to_buy field to clarify that it shows the amount immediately after the original authorization and does not reflect activity since the original authorization. This change affects this event only.
Clarified events in the Events API
In the Events API reference, following up on our July updates, we added more context to the descriptions of many more of our events, including what triggers the event and which processes may elicit that trigger. One example is the BAUT: auth event, which is triggered by you or Galileo approving an authorization request.
We plan to add similar context to the remaining event descriptions soon.
Correction to About Cards
From the About Cards guide we removed a statement that said that cards in
status: Z could not be reactivated.
New future scheduled payments object
In the response to the Get Scheduled Bill Payments endpoint there is a new object:
Card expiry and creation dates
For the Get Account Cards and Get Card responses, we are now returning a date in the
expiry_date field instead of a datetime, and for
created_date you have the option of getting a date or a datetime, depending on how a parameter is set.
Add ACH Account requirement
For the Add ACH Account endpoint we updated the description for the
name parameter to indicate that it is required unless you are using Plaid.
locale parameter we added
MX_es (Mexico Español) and
MX_en (Mexico English) as valid values. These endpoints are affected:
Correction to Creating a Provisioning Request
We updated the Creating a Provisioning Request guide and a couple of its corresponding recipes to remove two parameters that do not need to be passed in the Create Provisioning Request call:
clientWalletProvider. These values are instead provided by Galileo. This change applies only to calls made for Visa with Google Pay and Samsung Pay, and so those two recipes no longer include the parameters. The parameters have also been removed from the Create Provisioning Request endpoint reference.
Update to Digital First Program
To the Digital First Program guide we added information about using the IVR to set the PIN in the Protecting the physical card section.
Corrected Postman guide
In the Postman Setup guide we removed a note that said you needed to get a certificate for CV and Production. A certificate is not needed for those environments.
New guide and new recipes
We added a new guide, Creating a Provisioning Request, to accompany the About Mobile Wallets guide. With this new guide we're introducing a new feature called "recipes." Each recipe provides a code sample with narration to explain the elements of that sample, and you can click the clipboard icon to copy the code sample for your own use. For example, this recipe shows a Create Provisioning Request call when the wallet provider is Apple Pay.
You can find the recipes embedded in the guide and in the Create Provisioning Request endpoint reference as well as on a special Recipes page that you can access from the top menu.
To the About Mobile Wallets guide we added contact information for the wallet providers as well as two flowcharts:
New status code
The Reverse Adjustment endpoint has a new status code:
447-01 (Adjustment amount to be reversed does not match original transaction amount).
Clarified balance-related fields
In the response to the Get Balance endpoint we clarified the difference between the
Clarified field descriptions
The descriptions for the response fields have been clarified for these endpoints: