This guide explains how accounts are structured in the Galileo system and which account types are relevant to the API consumer. This guide does not explain the many account characteristics that a program or product may support.
## Account types
In the Galileo system, an account can be either a primary account or a secondary account. The purpose of creating secondary accounts is to create relationships between accounts in the Galileo system. In most cases, the related accounts all belong to the same customer, although the secondaries can also belong to someone else. In some cases, the secondaries are all business accounts that draw on the same fund.
It is up to you whether to use the primary/secondary linkage inside the Galileo system or whether to use your own logic to set up relationships among accounts. If you use the primary/secondary linkage in the Galileo system, the following will be true:
You can share account balances between a primary account and its secondary accounts.
The <<glossary:CST>> shows which accounts are related.
You can easily link naturally related accounts such as a <<glossary:DDA>> and its overdraft account.
You can add a secondary account to another secondary account, but only when using the <a href="ref:post_addaccount" target="_blank">Add Account</a> endpoint. With the <a href="ref:post_createaccount" target="_blank">Create Account</a> endpoint, secondaries must be linked to primaries only.
Galileo sets up and maintains the primary product parameters to indicate which products can be its secondaries, and also how many secondaries a primary account can have.
During customer onboarding the primary account must be created first and the secondaries later.
### Primary accounts
A primary account is the first account you create when onboarding a new customer. To create this account you must pass the customer's full name, address, and other personal information that goes into the customer record. You will also need this information to run <<CIP>> on the customer. (See <a href="doc:customer-id-verification" target="_blank">Customer ID Verification (KYC/CIP)</a> for more information.) In almost all cases you will use the <a href="ref:post_createaccount" target="_blank">Create Account</a> endpoint to collect and submit this information. (See <a href="doc:creating-an-account" target="_blank">Creating an Account</a> for instructions on using this endpoint.)
Primary accounts are typically DDAs with a debit card, but your use case may require a different type of primary account such as a health savings account, credit account, or instant-issue card.
### Secondary accounts
Secondary accounts represent additional products that a customer wishes to acquire, such as an overdraft account, a savings account, or an additional card. When creating a secondary account for a customer who already has a record in the Galileo system, you use the <a href="ref:post_addaccount" target="_blank">Add Account</a> endpoint. (See <a href="doc:adding-an-account" target="_blank">Adding an Account</a> for instructions on using this endpoint.)
It is also possible to create a secondary account that belongs to someone other than the primary account owner. For example, Gerry has a primary account for a debit card and his wife Sylvia also wants a debit card. Sylvia's card account can be created as a secondary account to Gerry's account. This arrangement makes it easy to retrieve data on both accounts at the same time. In this case you would use <a href="ref:post_createaccount" target="_blank">Create Account</a> so that you can create a customer record for Sylvia and verify her identity.
Things to keep in mind about secondary accounts:
A maximum of 3000 secondary accounts can be associated with a primary account; however, you may set a lower limit at the product level.
By default you cannot add multiple secondary accounts with the same product ID. To enable multiple secondary accounts with the same product ID, set SECLM on the secondary account.
A secondary account can belong to the same customer or it can belong to a different customer than the primary customer.
Product settings can dictate that a minor child meet a minimum age requirement to obtain a secondary account.
Note
Although there is no flag in the Galileo system to specifically mark primary and secondary accounts, you can view the relationships in the CST, or you can use the <a href="ref:post_getrelatedaccounts" target="_blank">Get Related Accounts</a> endpoint to retrieve related accounts.
### Primary and secondary account scenarios
These example scenarios demonstrate some of the ways to set up primary and secondary accounts.
#### One customer with multiple secondary accounts
In this scenario you offer these products:
**Product ID 5** — DDA with a debit card
**Product ID 9** — Overdraft account
**Product ID 4** — Savings account
A new customer, Leona Álvarez, signs up for the DDA. You create this account by calling <a href="ref:post_createaccount" target="_blank">Create Account</a> and include these input parameters:
Name, address and personal information
`
prodId: 5`
The endpoint returns 33333 as the <<glossary: PRN>> (`pmt_ref_no`) and 99999 as the <<glossary:PAN>>. The balance ID (`galileo_acct_no`) is 2222.
You offer an overdraft account for the DDA, and Leona opts in. You call <a href="ref:post_addaccount" target="_blank">Add Account</a> with these parameters:
`
accountNo: 33333``
prodId: 9`
The endpoint returns `pmt_ref_no: 66666` and balance ID 4444.
Leona also wants a savings account. You call Add Account again with these parameters:
`
accountNo: 33333``
prodId: 4`
The endpoint returns `pmt_ref_no: 77777` and balance ID 5555.
This is the end result of the above steps:
<!--about-accounts-primary-secondary-1.pngggggggg-->
#### Two customers with the same primary account
In this scenario you offer three products:
**Product ID 2** — DDA with a debit card
**Product ID 3** — A version of the above product that is designed for adolescents
**Product ID 8** — Savings account
A new customer, Adele Johnson, signs up for the DDA. You call <a href="ref:post_createaccount" target="_blank">Create Account</a> with these parameters:
Name, address and personal information
`
prodId: 2`
The endpoint returns `pmt_ref_no: 33333` and `99999` as the PAN. The balance ID is 0101.
Adele also wants the savings account, you call <a href="ref:post_addaccount" target="_blank">Add Account</a> with these parameters:
`
accountNo: 33333``
prodId: 8`
The endpoint returns `pmt_ref_no: 22222` and balance ID 1212.
Adele wants a card for her adolescent son Andy, and she wants Andy's account associated with hers. You call Create Account with these parameters:
Andy's name, address and personal information
`
prodId: 3``
primaryAccount: 33333`
The endpoint returns `pmt_ref_no: 66666` and `55555` as the PAN. The balance ID is 2323.
<!--about-accounts-primary-secondary-2.pngggggggg-->
Note
Do not confuse primary and secondary **accounts** with primary and secondary **products**. At the time program managers set up a product they have the option of creating a secondary product with a separate product ID. The secondary product typically has lesser features compared to the primary product—such as a lower spending velocity—and is intended for minors to use.
### Accounts for minors
If your program settings permit it, non-adult (under 18) customers can obtain secondary products. Specify the minimum age for eligible customers in the DOB product parameter. Where a minimum age is specified, the `dateOfBirth` parameter is required to ensure that the minor is eligible for the product.
## Joint accounts and shared balances
It is not currently possible to set up true joint accounts in the Galileo system, wherein one account has multiple account holders. Instead, you can use the shared balance feature. A shared balance is a bank account that multiple products (accounts) can transact on. The accounts can belong to the same customer or to different customers.
With shared balances you can support scenarios such as these:
A customer wants multiple products from the same provider and wants all of those accounts to transact on the same bank account.
A parent wants a separate card for a child, and both the parent and child will transact on the same bank account.
A customer wants to add a virtual card to share the same bank account as their physical card.
Two spouses want the same product, and want both product accounts to transact on the same bank account.
If you are planning to use a high number of secondary accounts with shared balances for corporate spending cards, Galileo offers two solutions: <a href="doc:about-real-time-funding" target="_blank">Real-Time Funding</a> for debit accounts and <a href="doc:about-corporate-credit" target="_blank">Corporate Credit</a> for credit accounts. These solutions scale better than using shared balances and provide superior reporting and account management.
A secondary account can share a balance only with the specified primary account.
Warning
Once you share a balance between accounts, you cannot "unshare" the balance. Instead, you would have to close the accounts and create new ones without shared balances. Likewise, you cannot share balances after the accounts have already been created.
### Shared balances scenarios
The following scenarios demonstrate some of the ways to set up shared balances.
#### One customer, two products
In this scenario, Ana Ramírez, an existing customer, wants another product and would like the second product to transact on the same bank account as the first product.
You already called the <a href="ref:post_createaccount" target="_blank">Create Account</a> endpoint to create Ana's first account (primary account), with PRN 444 and balance ID 2222. To create the secondary account with a shared balance, call the <a href="ref:post_addaccount" target="_blank">Add Account</a> endpoint with these parameters:
<!--about-accounts-shared-balance-1.pngggggggg-->
#### Two customers, one product
In this scenario an existing customer, Simón Ramírez, wants to add an account for his son, Simón Ramírez, Jr. The product IDs are:
**Product ID 6** — DDA with a card
**Product ID 7** — DDA with a card, configured specially for adolescents
<!--about-accounts-shared-balance-2.pngggggggg-->
### Getting related account information
With some transaction-retrieval endpoints, you can use the `includeRelated` parameter to get information for all accounts that share the same balance. If `accountNo` contains a secondary account, set the parameter like this:
`
includeRelated: 0` — Return data only for this secondary account.`
includeRelated: 1` — Return data for all accounts that share the same `balance_id`.
If `accountNo` contains a primary account, the data for all accounts that share the same `balance_id` are returned by default, so there is no need to set `includeRelated`.
For example, with the <a href="ref:post_gettranshistory" target="_blank">Get Transaction History</a> endpoint, these are the possible results for the _Two customers, one product_ scenario, above:
`accountNo` | `includeRelated` | Return |
`333` | `0` | Transactions for Simón Ramírez Jr. only |
`333` | `1` | Transactions for both Simón Ramírez and Simón Ramírez Jr. |
`444` | _blank_ | Transactions for both Simón Ramírez and Simón Ramírez Jr. |
## New account creation
In most cases you will use <a href="ref:post_createaccount" target="_blank">Create Account</a> to create a customer record and a corresponding account record. Other endpoints that create a customer record are:
<a href="ref:post_startenrollment" target="_blank">Start Enrollment</a> — Creates a customer record but not an account. Use this endpoint when you want to wait until after a customer passes ID verification before creating an account. See <a href="doc:customer-id-verification#start-enrollment-process" target="_blank">Start Enrollment process</a> in _Customer ID Verification (KYC/CIP)_ for more information.
<a href="ref:post_createvirtualcard" target="_blank">Create Virtual Card Account</a> — Creates a virtual card and returns the full PAN. You must be PCI-compliant to use this endpoint, and the product ID must be for a virtual card.
#### Customer record fields
Customer name
Customer billing address
Customer shipping address
Phone numbers
Date of birth
Email address
Identifiers such as SSN or driver license number
Occupation and income source
#### Account record fields
**PRN** — Payment reference number. A Galileo-generated account identifier that is unique across the Galileo system. This is the primary identifier for an account.
**Status** — The account status. See the <a href="ref:api-reference-account-statuses" target="_blank">Account Statuses</a> enumeration.
**Balance** — The amount of funds present in the account that is available to spend.
**Balance ID** — An identifier that corresponds to the bank account where customer funds reside.
**Application date** — The date the customer is first onboarded to the Galileo system.
**Currency code** — The denomination of the funds, such as U.S. dollar or Mexican peso.
**Routing number** — The identifier for the bank where the account's funds reside.
**Product ID** — The identifier for the specific offering of a program.
**Customer record ** — The information in the customer record.
**Savings interest object** — Where applicable, the amount of interest accrued.
**Transactions** — List of settled transactions made on the account.
**Authorizations** — List of pending authorizations for the account.
**Pending fees** — List of fees to be charged to the account.
**Holds** — List of holds for the account.
#### Card record fields
See <a href="doc:retrieving-card-information#card-records" target="_blank">Card records</a> in _Retrieving Card Information_ for the fields.
## Create Account vs Add Account
Whether to use the <a href="ref:post_createaccount" target="_blank">Create Account</a> endpoint instead of <a href="ref:post_addaccount" target="_blank">Add Account</a> is determined by whether the customer already exists in the Galileo system:
**Create** an account to onboard new customers, including a new customer who will be the owner of a secondary account.
**Add** an account to an existing customer who wants additional products such as savings or overdraft accounts. You cannot use Add Account to deposit funds into the account, nor does it run <<glossary:CIP>>. For more information on how to add overdraft accounts, see <a href="doc:creating-an-overdraft-account" target="_blank">Creating an Overdraft Account</a>.
### Create Account and Add Account use cases
| Use case | Endpoint | Parameters |
| Onboard a new customer | <a href="ref:post_createaccount" target="_blank">Create Account</a> | <li>`primaryAccount` — Do not populate <li>`prodId` — Any product ID<li>`sharedBalance` — Do not populate. |
| Add a secondary account (another product) to an existing customer | <a href="ref:post_addaccount" target="_blank">Add Account</a> | <li>`accountNo` — Primary account of existing customer<li>`prodId` — Must be permitted by the primary account product settings<li>`sharedBalance` — (Optional) `1` to share the balance with the primary account; otherwise, set to `0` or do not populate |
| Add an account for a dependent minor (under 18) to a parent's account, with shared balance | <a href="ref:post_createaccount" target="_blank">Create Account</a> | <li>`primaryAccount` — Parent's primary account<li>`prodId` — Secondary product ID; must be permitted by the primary account product settings<li>`sharedBalance` — Required. `1` to share the balance with the primary account<li>`cipStatus` — `2` if you are using Galileo's CIP; otherwise, do not populate<li>`dateOfBirth` — Required if product settings have a minimum age |
| Add an account for a child to a parent's account, without shared balance | <a href="ref:post_createaccount" target="_blank">Create Account</a> | <li>`primaryAccount` — Parent's primary account<li>`prodId` — Secondary product ID<li>`sharedBalance` — Required. Set to `0` <li>`cipStatus` — `2` if you are using Galileo's CIP; otherwise, do not populate<li>`dateOfBirth` — Required if product settings have a minimum age |
| Onboard a new customer who will be sharing a balance with an existing customer's account | <a href="ref:post_createaccount" target="_blank">Create Account</a> | <li>`primaryAccount` — Primary account of existing customer<li>`sharedBalance` — `1` |
| Create a virtual card account for a new customer (You must be PCI compliant to use this endpoint.) | <a href="ref:post_createvirtualcard" target="_blank">Create Virtual Card Account</a> | <li>`primaryAccount` — Do not populate<li>`prodId` — Must be a virtual product |
| Add a virtual card account to an existing customer, and the virtual card has a different PAN than the primary card. (You must be PCI compliant to use this endpoint.) | <a href="ref:post_createvirtualcard" target="_blank">Create Virtual Card Account</a> | <li>`primaryAccount` — Primary account of existing customer<li>`prodId` — Must be a virtual product<li>`sharedBalance` — Required. Pass `1` to share the balance with the primary account; otherwise, set to `0`. |
## Account identifiers
In the Galileo system you will encounter several types of account identifiers:
#### PRN
The payment reference number is a unique, 12-digit Galileo-generated account identifier. Galileo recommends that you use this number to identify accounts, instead of card numbers or customer IDs, because a PAN can change but a PRN never does. A permanent identifier prevents maintenance headaches when the other identifiers change.
The PRN comprises three parts:
3-digit prefix, unique per Galileo client
8-digit account number, which in new programs begins with 101 and increments to 102 when the five remaining digits are exhausted. These digits can be generated in sequence or randomly, according to your settings.
1-digit checksum
The PRN is also the number that customers provide to their banks when setting up <<glossary:ACH>> accounts or when setting up direct deposit from an employer. The Program API returns the PRN as `pmt_ref_no`.
In most cases, you can use the PRN for `accountNo` in the Program API; however, some endpoints will return an error if there are multiple cards associated with the PRN (not multiple secondary accounts). In that case, use the PAN or the <<glossary:CAD>>, if the endpoint supports it.
#### PAN
The primary account number is the globally unique 16-digit number that is displayed on a card. The first 6–8 digits are the <<glossary:BIN>>, which is assigned by your bank. If you are PCI compliant, you can receive the full PAN in Program API responses, Events API messages, the <<glossary:RDF>>s and the <<glossary:CST>>. If you are not PCI compliant you receive a masked PAN. The PAN is also called the "card number".
See <a href="doc:setting-up-a-card-program#card-elements" target="_blank">Card elements</a> in the _Setting Up a Card Program_ guide for more information.
#### Galileo account number
Also called the "balance ID," the Galileo account number is an identifier that points to the bank account that the product transacts on. The Program API returns the balance ID as `galileo_account_no`.
Do not pass this number for `primaryAccount` or `accountNo`.
#### External account ID
An external account ID is a number you provide that can be used for your own purposes. Some examples uses of this value are:
Mapping the customer account to your back-end systems
Communicating with the embosser to specify which art to use on the card (See <a href="doc:design-a-card#specifying-a-card-design" target="_blank">Specifying a card design</a> in the _Design a Card_ guide for more information.)
The `externalAccountId` parameter is passed in the <a href="ref:post_createaccount" target="_blank">Create Account</a> endpoint. You can retrieve the external account number with the <a href="ref:post_verifyaccount" target="_blank">Verify Account</a> endpoint and edit it with the <a href="ref:post_updateaccount" target="_blank">Update Account</a> endpoint.
Do not pass this number for `primaryAccount` or `accountNo`.
#### ACH account number
An ACH account points to a customer's external bank account, which can be used for such transactions as direct deposit and interbank transfers. An ACH account is set up using the <a href="ref:post_addachaccount" target="_blank">Add ACH Account</a> endpoint. See <a href="doc:about-ach" target="_blank">About ACH</a> for more information.
### Account identifiers in the Galileo system
This table is a summary of how account identifiers are represented across the Galileo system.
| Galileo system | PRN | Galileo account number | External account ID | ACH account number |
| Auth API | `prn` | n/a | n/a | n/a |
| Events API | `prn` | `balance_id` | n/a | `ach_acct_id` |
| External Trans API | `account_number`<br>`prn` | n/a | n/a | n/a |
| Program API requests | `accountNo`<br>`primaryAccount` | n/a | `externalAccountId` | `achAccountNo` |
| Program API responses | `pmt_ref_no` | `galileo_account_no`<br>`bal_id` | `external_account_id` | `ach_account_id` |
| RDFs | `PRN` | `GALILEO ACCOUNT ID` | `EXTERNAL ACCOUNT NUMBER` | n/a |
## Virtual card accounts
A virtual card exists only on a customer's mobile device, on the web, or in an email: it is not issued as a physical card. See <a href="doc:choose-a-card-strategy#digital-cards" target="_blank">Digital cards</a> in the _Choose a Card Strategy_ guide and <a href="doc:setup-for-virtual-cards" target="_blank">Setup for Virtual Cards</a> for information on virtual card accounts.
## Account status
An account's status is designated by a single capital letter in the Galileo system, as shown in the <a href="ref:api-reference-account-statuses" target="_blank">Account Statuses</a> enumeration.
Note
Account status is not the same as card status. The statuses may be similar in some cases, but they operate independently. See the <a href="ref:api-reference-card-statuses" target="_blank">Card Statuses</a> enumeration.
By default, when a card account is first created, it is in `status: W` (waiting to be processed). (For a different default status, set the XAACT parameter.) The Galileo system runs an account-setup process, a cron job that runs every 5–30 minutes, depending on your product settings. When successful, the account is put into its next state, according to your product parameters. Most virtual card accounts and <a href="doc:choose-a-card-strategy#digital-first-cards" target="_blank">Digital First card accounts</a> are put into `status: N` (active). A conventional physical card would be moved into `status: X` (waiting for emboss).
An emboss process periodically checks for physical card accounts in `status: X` and collects the emboss information to send to the card embosser. At this point the account is moved to `status: Y` (ready to activate), and when the card is mailed to the cardholder and activated it is changed to `status: N` (active). See the <a href="doc:card-statuses" target="_blank">Card Statuses</a> guide for information on how card statuses change during the emboss process.
To manually change an account status, use the <a href="ref:post_modifystatus" target="_blank">Modify Status</a> endpoint. Consult <a href="ref:api-reference-modify-status-codes" target="_blank">Modify Status Codes</a> for a list of values for the `type` parameter. Be sure that the Modify Status `type` changes exactly what you want: the account status, the card status or both.
## Account features
Most of an account's features are set at the product level; however, a few features can be set or modified at the account level, such as allowing international transactions or sending paper statements. To set or change these features use the <a href="ref:post_setaccountfeature" target="_blank">Set Account Feature</a> endpoint. Defaults for some of these features can also be set at a product level. Contact Galileo to set these defaults.
Also see <a href="doc:about-account-level-auth-controls" target="_blank">About Account-Level Authorization Controls</a> for authorization limits to set at an account level.
## Depositing funds into accounts
According to your product settings you have the option to deposit funds into an account at the time of account creation or you can deposit funds later. Customers can also deposit funds into their accounts if your product settings permit it. The sooner funds are deposited into a debit account, the more likely the cardholder is to start spending and to stick with the product.
Consult this table to see how to use the endpoints for each use case.
| Use case | Endpoint | Parameters |
| Deposit funds into an account at the time of account creation; typically for <a href="doc:choose-a-card-strategy#instant-issue-cards" target="_blank">instant issue</a> and gift cards | <a href="ref:post_createaccount" target="_blank">Create Account</a> | <li>`loadAmount` — Must be within the limits in your product settings<li>`loadType` — Valid values assigned by Galileo to each client<li>`loadFromAccountNo` — Use only if you have created an account within the program for depositing funds into customer accounts |
| Deposit funds into the account at a time other than account creation, using the account you have set up with Galileo for depositing funds into customer accounts | <a href="ref:post_createpayment" target="_blank">Create Payment</a> | <li>`accountNo` — Account to receive the deposit<li>`type` — Value assigned to you by Galileo |
| Deposit funds into the account at a time other than account creation, using an account within your program for depositing funds into customer accounts | <a href="ref:post_createaccounttransfer" target="_blank">Create Account Transfer</a> | <li>`accountNo` — Account to transfer funds from<li>`type` — Value assigned to you by Galileo <li>`transferToAccountNo` — Account to receive the deposit |
| Customer deposits funds into their account from an external bank account | <a href="ref:post_createachtransaction" target="_blank">Create ACH Transaction</a> | <li>`accountNo` — Account to receive the deposit<li>`achAccountId` — The ACH account to draw from<li>`debitCreditIndicator` — `D` to move funds from the ACH account into the customer account |
| Customer sets up recurring deposits from an employer or benefits agency | <a href="doc:direct-deposit-switch" target="_blank">Direct Deposit Switch</a> product | See <a href="doc:setting-up-direct-deposit-switch" target="_blank">Setting Up Direct Deposit Switch</a> for instructions. |
| Customer deposits funds into their account from another account that they have with you | <a href="ref:post_createaccounttransfer" target="_blank">Create Account Transfer</a> | <li>`accountNo` — Account to transfer funds from<li>`transferToAccountNo` — Account to receive the deposit |
## Retrieving account information
Use these endpoints to retrieve the desired account information..
#### Column header key
**A** — <a href="ref:post_getbalance" target="_blank">Get Balance</a>
**B** — <a href="ref:post_getaccountoverview" target="_blank">Get Account Overview</a>
**C** — <a href="ref:post_getaccountfeatures" target="_blank">Get Account Features</a>
**D** — <a href="ref:post_getaccountbyid" target="_blank">Get Account</a>
**E** — <a href="ref:post_verifyaccount" target="_blank">Verify Account</a>
**F** — <a href="ref:post_getinterest" target="_blank">Get Interest</a>
**G** — <a href="ref:post_getsavingsinterest" target="_blank">Get Savings Interest</a>
**H** — <a href="ref:post_getoverdraftbalance" target="_blank">Get Overdraft Balance</a>
| Attribute | A | B | C | D | E | F | G | H |
| PRN | | X | | X | X | | | |
| Balance | X | X | | X | X | | | |
| Currency code | X | | | | | | | |
| Status | | X | | X | X | | | |
| Product ID | | | | | X | | | |
| Galileo account no. (balance ID) | | | | | X | | | |
| Merchant category code | | X | | | | | | |
| Application date | | X | | | | | | |
| Customer record | | X | | | | | | |
| Transaction count | | X | | | | | | |
| Transactions (list) | | X | | | | | | |
| Authorization count | | X | | | | | | |
| Authorizations (list) | | X | | | | | | |
| Pending fees (list) | | X | | | | | | |
| Interest object | | X | | | | | X | |
| Savings interest object | | X | | | | | X | |
| Account features (array) | | | X | | | | | |
| Max load amount | | | | | X | | | |
| External account ID | | | | | X | | | |
| Overdraft balance (array) | | | | | | | | X |
## Modifying account information
After you have created a new account you can modify customer record attributes using the <a href="ref:post_updateaccount" target="_blank">Update Account</a> endpoint, as long as the account is active (`status: N`). When sending the Update Account call, you pass only the parameters to be modified. Parameters that are not being modified can be left blank. Do not pass `null` unless you want to set the parameter's value to null.
Note
According to the settings in your product parameters, some customer record information may not be modifiable or nullable. See <a href="ref:post_updateaccount" target="_blank">Update Account</a> for details.
You can input either a primary or secondary account number to change the associated customer record attributes.
### Switching to a new product
You can change the product ID for an account by following the steps in <a href="doc:switching-products" target="_blank">Switching Products</a>.
## Closing accounts
Because the Galileo system is an official system of record, it is not possible to delete an account from the Galileo system. Legal requirements specify that all activity, including account creation, be stored for a period of several years for auditing purposes.
However, an account may be closed, which prevents further transactions from being made on it and deactivates any cards associated with it. The <a href="ref:api-reference-account-statuses" target="_blank">Account Statuses</a> enumeration shows which transactions are valid for each account status.
Your product settings determine some of the events that trigger an account closing, such as an account having zero or negative balance for a specified period. Other events such as a stolen or lost card can result in a closed account. (See <a href="doc:lost-stolen-or-damaged-cards" target="_blank">Lost, Stolen, or Damaged Cards</a>.)
Your product settings also determine which procedures must be followed when an account is closed, such as whether to send a check for the remaining balance or whether the cardholder must return the card before receiving a check. See <a href="doc:account-holder-refund" target="_blank">Account Holder Refund</a> for more information.
This table shows some of the states that can represent a closed or unusable account and the `type` parameter in the <a href="ref:post_modifystatus" target="_blank">Modify Status</a> endpoint that moves the account to that status. See <a href="ref:api-reference-modify-status-codes" target="_blank">Modify Status Codes</a> for all Modify Status types. Follow your business plan to decide when to use these Modify Status types. Also see <a href="doc:setting-up-a-card-program#card-cancelation" target="_blank">Card cancelation</a> in the _Setting Up a Card Program_ guide.
Note
If the card is in `
status: N` but the account is in a canceled status, the card cannot be used.
| Use case | Type | Account status | Notes |
| Close the account | 2 | `C` | <li>Changes the account to `status: C` but does not change the status of associated cards. <li>When the account is closed the cards cannot be used. |
| Deactivate account and cancel cards | 13 | `C` | <li>Changes both the account and associated cards to `status: C`.<li>Does not close related savings accounts. |
| Deactivate account and cards | 16 | `Z` | <li>Changes both the account and associated cards to `status: Z`.<li>Does not affect related secondary accounts. |
| Cancel without refund all accounts and cards for a customer and all related accounts and cards | 20 | `Z` | <li>Changes both the account and associated cards to `status: Z`.<li>Affects all accounts and cards of the customer, including secondaries. |
| Disable account and active cards | 23 | `D` | <li>Changes both the account and associated cards to `status: D`. <li>Does not affect related secondary accounts. |
## Reversing an account creation
If you have created an account in error, follow these steps:
**Optional.** Call <a href="ref:post_updateaccount" target="_blank">Update Account</a> to set the `
id` and `id2` values to null, so that the customer can attempt to join again.Call <a href="ref:post_modifystatus" target="_blank">Modify Status</a> with `
type: 2` to cancel the account.
Alternatively, you can use the Customer Service Tool to cancel the account.
## Events API
These event messages represent stages in account creation and management. You can arrange with Galileo to receive the events that correspond to your use case. Some of the events are triggered only by actions taken in the CST, others only by the Program API, and others by both. Click the event to see details:
<a href="ref:api-reference-events-api-app-completed" target="_blank">`
CAPP: app_completed`</a> — Account creation is successful.<a href="ref:api-reference-events-api-pass-id" target="_blank">`
PTID: pass_id`</a> — The customer passed Galileo's integrated ID verification<a href="ref:api-reference-events-api-fail-id" target="_blank">`
FTID: fail_id`</a> or <a href="ref:api-reference-events-api-failed-id" target="_blank">`BFID: failed_id`</a> — The customer failed ID verification<a href="ref:api-reference-events-api-account-status-change" target="_blank">`
ACST: account_status_change`</a> — Account status changed (in some circumstance)<a href="ref:api-reference-events-api-addr-chg" target="_blank">`
ADRC: addr_chg`</a> — The Program API updated the customer's primary address<a href="ref:api-reference-events-api-email-addr-change" target="_blank">`
ECHG: email_addr_change`</a> — The Program API or CST updated the customer's email address.<a href="ref:api-reference-events-api-phone-changed" target="_blank">`
PHCH: phone_changed`</a> — One of the customer's phone numbers was changed.<a href="ref:api-reference-events-api-profile-changed" target="_blank">`
PCHG: profile_changed`</a> — The CST changed customer profile information.<a href="ref:api-reference-events-api-cardholder-info-changed" target="_blank">`
CHPC: cardholder_info_changed`</a> — The CST changed customer profile information.<a href="ref:api-reference-events-api-neg-bal" target="_blank">`
BNEG: neg_bal`</a> — The account has a negative balance today.<a href="ref:api-reference-events-api-low-balance-notify" target="_blank">`
LBLC: low_balance_notify`</a> — The balance has dropped below a specified amount.<a href="ref:api-reference-events-api-account-closed" target="_blank">`
ACCL: account_closed`</a> — The CST closed a customer account.