Log into Sandbox

Transaction History

Suggest Edits

This guide contains instructions for presenting your account holders' transaction histories. Along with this guide you might want to read these other guides:

You need to access your account holders' transaction histories for reasons such as these:

  • Present to account holders their transaction histories on your app or website
  • Send account holders a monthly statement, summarizing all transactions during that period
  • Analyze transaction data for various purposes, such as spending categorization

API-first strategy

Galileo recommends the API-first strategy to all new clients. Legacy clients might also find that API-first is a better solution for them, because it doesn't include building a datastore that attempts to parallel the Galileo ledger in real time.

📘

Note

The legacy method, which may be better for programs that maintain their own account balances, has been moved to Building a Transaction Datastore.

Presenting recent transaction history

Transactions younger than 30 days are often in a state of flux: a pending authorization can be reversed, it can settle for a different amount, or it could expire. ACH and billpay transactions are sometimes returned and reversed. This variability presents a challenge when trying to display the latest information to your customers. The most reliable way to present current data is to call the Program API every time a customer accesses a page in your app or website; however, that can result in an undesirably high number of API calls, and if the transactions are older than 30 days, the response from the Program API can be unacceptably delayed.

To ensure that you always present the latest version of the data, while minimizing the number of API calls, Galileo recommends an "API-first" strategy for transactions that are younger than 30 days old. (For transactions older than 30 days, go to Presenting older transaction history). The API-first strategy combines the Program API with the Events API to maintain a cache that always contains the latest data.

The API-first strategy follows this process:

  1. A customer accesses your web site or mobile app for the first time.
  2. You call the Program API and cache the response.
  3. The interface retrieves the data from the cache and presents it.
  4. The next time the customer accesses the interface, you do one of the following, depending on whether you have received an Events API message for the account:
    • No message received — Present the cached data.
    • Message received — Call the Program API again, overwrite the data in the cache, and present the new data.

API-first setup

To follow the API-first strategy, you will need to set up the following:

  • Decide which Program API endpoints you want to call to present data in your interface.
  • Create a datastore to hold the responses from the Program API. This datastore will act as a cache that your interface always draws on when presenting data.
  • Subscribe to Events API messages that are triggered by balance changes, according to your use case.
    • If you will also present customer profile information (using Get Account Overview), you should also subscribe to the Account Events webhooks that indicate a change to the customer profile.
  • Decide on a "staleness" interval, which determines how old a cached response can be before it is considered expired.
  • Consume the daily Posted Transactions RDF as well as any of the Service RDFs or Product RDFs you might want.
  • Create another datastore to hold the transactions from the RDFs.
Conventions
  • The interface must always draw from a "clean" cache. A clean cache has the latest account data.
  • When the cache is not clean, it must be refreshed by calling the Program API.
  • Two conditions affect whether the cache is clean:
    • Staleness interval — After this interval, the data is considered to be "stale."
    • Events API messages — The arrival of an event automatically invalidates the cached data, rendering it "dirty."
  • As desired, you can add your own enriched data to the cache before presenting the data to the customer.

API-first workflow

  1. When the customer logs in to the interface for the first time, the interface calls the Program API to populate the cache.
  2. The interface pulls data from the cache to present to the customer.
  3. The cache is considered clean until one of these things happens:
    • An Events API message arrives.
    • The staleness interval elapses.
  4. The next time the customer accesses the interface, application logic determines whether the cache is clean.
    • Not clean — The interface calls the Program API to refresh the cache.
    • Clean — The interface does not call the Program API.
  5. The interface pulls data from the cache to present to the customer.

Presenting older transaction history

Transactions older than 30 days are almost always stable. Pending authorizations have usually expired, and ACH and billpay returns don't usually take a month. To retrieve these transactions, you can use a datastore that you have created from the daily RDF files that Galileo sends.

This is the process:

  1. Read the daily Posted Transactions RDF and other RDFs into a separate datastore. See Building a datastore in the About the Raw Data Files (RDFs) guide for more information.
  2. A customer accesses your interface to see a list of transactions that are older than 30 days.
  3. You retrieve the transactions from your RDF datastore to present to the customer.

Data sources

Galileo offers these data sources for you to present a transaction history:

Events API

The Events API comprises these transaction-related message types that you can subscribe to:

  • Authorization Events — Based on notifications from card networks when a card transaction is authorized
  • Settlement Events — Based on notifications from card networks when an authorized transaction is cleared
  • Transaction Events — Notifications from the Galileo system about payments, adjustments, fees, and holds

See About the Events API for more information.

RDFs

Every day Galileo sends you RDFs containing an authoritative list of transactions that took place in your program during a 24-hour period. You can use these files to verify that your transaction history is accurate. You can also create new records in your transaction history from these files if your record is missing any transactions.

For more information see the About the Raw Data Files (RDFs) guide. Also see Transaction IDs for information on constructing unique IDs for each transaction.

📘

Note

Galileo strongly recommends that you use your RDF datastore when creating customer-facing statements and performing data analysis.

Program API

When calling the Program API to present data to the customer, choose the endpoint according to your use case:

Account landing page

When your customers open your app or go to your website, they expect to see a snapshot of relevant information: balance and recent transactions are common items to display. For this use case, Galileo recommends the Get Account Overview endpoint. It returns:

  • Customer profile information
  • Account balance (available funds for debit or unpaid balance for credit)
  • Pending card purchases
  • Posted transactions, including settled authorizations, deposits, withdrawals, and fees

You can specify a date range for the transactions to display. Also included are:

  • PRN (account number)
  • Card shipping address
  • Pending fees
  • Holds
  • Savings / non-Savings interest

Balance only

If you want to show only the available balance on your interface, use the Get Balance endpoint. It returns:

  • Available balance
  • Pending billpay transactions
  • Balance without including card transactions

You can also get the balance from the Get Account Overview endpoint response, but that endpoint returns a large amount of data, which might increase latency.

Completed transactions

To show only the transactions that have been posted to the account (not including pending transactions), call the Get Transaction History endpoint. For the specified timespan, it returns:

  • Settled card transactions
  • Deposits
  • Withdrawals
  • Transfers
  • Fees

Pending transactions

Pending card transactions—authorizations that have not settled, expired, or been reversed—are returned by the Get Authorization History endpoint.

Declined transactions

To show all declined or rejected transaction types, you have to combine the results of a few endpoints:

Billpay transactions

With billpay transactions you can display a list of all payments for all billers, or you can list the transactions per biller. Call Get Bill Payment History for a specified timespan or call Get Scheduled Bill Payments for payments that are scheduled for future dates.

Deposits

You can display funds that are deposited into a customer account by calling one of several endpoints:

  • Get Deposit History — During program setup, you can specify which kinds of ACH deposits are returned by this endpoint.
  • Get ACH Transaction History — This endpoint returns all ACH transactions. You can filter out the debits to display only the credits.
  • Get Payment History — This endpoint returns all funds that credit the account, regardless of source.

Transfers

You can define transfers as bank-to-bank transfers (ACH transactions) or you can include peer-to-peer funds movement.

  • Get ACH Transaction History — Returns all bank-to-bank transfers, both incoming and outgoing.
  • Get Transaction History — Select transactions that have MCCs for peer-to-peer funds movement. You might need to do a bit of research to find which MCCs apply to your use case.

Fees

To display fees by themselves, call one of these endpoints:

Holds

To show holds on an account, you can call Get Hold History, which displays holds that you created with the Create Hold endpoint.

Updated 4 months ago