Setting ALCs

This guide contains general information on how to set account-level authorization controls (ALCs) as well as how to set up the use cases in the Account-Level Authorization Controls guide.

This guide assumes that you are familiar with the concepts in these guides:

• Account-Level Authorization Controls — General explanation of ALCs, including use cases.
• Designing Authorization Controls — How to design authorization controls at the product and account levels.
• MCC and Merchant ID ALC Examples — Tables that show how MCC and merchant ID controls are applied.

Result of following these procedures

An ALC is created, modified, disabled, or deleted. The authorization controls can also be retrieved per account or per product. You can set three types of ALC:

• Set Velocity Controls
• Set MCC Controls
• Set Merchant ID Controls

General ALC characteristics

These are the general characteristics of ALCs:

• To update an existing ALC, send another Set Account-Level X Control call with the new values.
• After setting or updating an ALC, there is a delay of a few minutes before the control is applied to live transactions.
• ALCs are applied to PRNs, not to card IDs or balance IDs:
  • All cards that have the same PRN are affected by the ALC. If card1 and card2 have the same PRN, it is not possible to put an ALC on card1 but not card2.
  • When two or more PRNs share an account balance (bal_id), the ALC applies only to the individual PRNs, not to the bal_id. For example, if PRN1 and PRN2 share a balance, an ALC that is applied to PRN1 will not affect PRN2.

Setting time limits

All ALCs can be set either permanently or for a limited time. The startDate and endDate endpoint parameters have these defaults:

• startDate: Current Galileo system time
• endDate: 1 Jan 3000 (no expiry)

When you pass nothing or Null for these values, the defaults are applied in these circumstances:

• The control is being created for the first time
• Velocity ALCs only. The control was disabled (not deleted) or expired and you are reactivating it.

For example, if a velocity control has expired, then the next time you call Set Account-Level Auth Control for that control—and you pass nothing or Null for the start or end dates—the default values will be applied.

However, if a control has not expired, and you want to update one of its parameters, passing nothing or Null for startDate or endDate will not nullify the values in those fields; instead, the previous values are preserved. You must pass new values for the date fields to change them.

• For MCC or merchant ID controls that have expired, you cannot pass nothing or Null to get the default date values; instead, you must enter new values.
• You can set startDate up to six months in the future. endDate must always be later than startDate.

🚧

Warning

Do not pass a time for startDate or endDate that is in the past, even if it is a time that has already been set. Instead, pass no value to keep the same value, or pass a value that is equal to or later than the current system time.

This table shows some examples of setting the dates in a Set Account-Level X Control endpoint, assuming that today is March 10, 2024 at 1:00 pm.

Use cases

These use cases are examples of how to set the ALCs in the Use cases section in Account-Level Authorization Controls. All examples assume that today is March 10, 2024 at 1:00 pm in Galileo system time.

Use case 1: Setting multiple cardholder tiers

You establish two tiers above the default level for cardholders who qualify for the increased limits. You have set up logic to determine which cardholder qualifies for which tier. When you determine that a cardholder qualifies, you set an ALC for each of the five product-level controls, and the limits do not expire. Because you are increasing the limits on five controls, you send five calls to Set Account-Level Auth Control, one for each control ID. This example shows how to set a new amount and transactionCount for the first control (Daily domestic ATM withdrawal limit).

Use case 2: Raise international ATM limits

Raise international daily ATM limits to $800 with the transaction count raised to 20 during a cardholder's vacation, from March 20 to March 26. Call Set Account-Level Auth Control with these parameters:

Use case 3: Reduce a limit

Reduce the total weekly amount to $3000 with transaction count set at 7. The change starts at 1:00 pm (now) and does not expire. Call Set Account-Level Auth Control with these parameters:

Use case 4: Change count but not amount

Raise the domestic ATM transaction count limit to 4 but do not change the amount, starting now (1:00 pm) and ending in 30 minutes. After the ALC expires, the account reverts back to the product-level controls. Call Set Account-Level Auth Control with these parameters.

Use case 5: Fleet-card controls

The fleet-card product has an MCC control of 5530–5549 ALLOW, which permits purchases at gas stations and auto parts stores only. For those drivers who regularly need to make overnight stays, call the Set Account-Level MCC Controls endpoint with these parameters to allow the card to be used at hotels.

Use case 6: Food-delivery cards

The food-delivery driver cards have a product-level MCC control of 0000–0000 ALLOW, which means that all MCCs are denied. The merchant ID controls are valid for only one hour. When an order comes in for Restaurant A, you retrieve Restaurant A's merchant ID from a lookup table that you maintain for all affiliated restaurants. Call the Set Account-Level Merchant Control endpoint with these parameters:

Use case 7: Teen spending cards

See Velocity MCC examples in MCC and Merchant ID ALC Examples for the product-level and account-level controls that the parents set for their teen's card.

To set the ALCs call the Set Account-Level Auth Control endpoint with these parameters: