# Automatic Charging Concepts

An automatic charge is made by Elastic Access for items currently in use in a session. The automatic charge is applied once per hour after the last successful access request. It is a way for the application to continue using items over an extended period without having to repeat requests to Elastic Access at precisely the right time.

Automatic charging for items ensures that there are enough tokens available to pay for use of an item before its use is continued.

If an automatic charge fails to find sufficient tokens for the items being used in the session, Elastic Access does the following:

- Places the session in a TERMINATED state.
- No longer accepts access requests for the session.
- Responds to a heartbeat with an error.


The following two example scenarios illustrate the sequence of steps for automatic charging during sessions. In these examples, the automatic charging interval is displayed in minutes (each interval lasts one hour).

- Scenario 1: Simple Repeated Automatic Charging
- Scenario 2: Mid-session Charges


## Scenario 1: Simple Repeated Automatic Charging

This first scenario shows how automatic charging for one item looks over time.

This is the sequence of events:

1. **0 minutes**: Start of timeline. The client application requests an item. Elastic Access makes initial charge 1 and sends usage information to the data warehouse.
2. **60 minutes**: Automatic charge 2 is made after one hour (60 minutes). Again, relevant usage information is immediately sent to the data warehouse.
3. **Between 60 and 120 minutes**: Within 30 minutes of charge 2, the client application sends a heartbeat to keep the session active.
4. **120 minutes**: Automatic charge 3 is made at 120 minutes. Usage information is sent to the data warehouse.
5. **140 minutes**: Twenty minutes after charge 3, the client application ends the session. Elastic Access immediately calculates for how long since the start of automatic charge 3 the client has used the item (20 minutes) and issues a refund for the remainder of the automatically charged time (40 minutes). Elastic Access applies the refund to the internal record.


The following diagram shows the sequence of steps:

![PAS_SessionExRepeatCharging.png](/assets/pas_sessionexrepeatcharging.ce9db89bc61ce5900e842f8d54c26313a17676bfcea2d406f37107556bc256d5.9bb1daa4.png)

## Scenario 2: Mid-session Charges

In this scenario, the client does not end the session between automatic charges. Instead, it requests an additional item—item B—twenty minutes after automatic charge 3.

This is the sequence of events:

1. **0 minutes**: Start of timeline. The client application requests item A. Elastic Access makes initial charge 1 and sends usage information to the data warehouse.
2. **60 minutes**: Elastic Access makes automatic charge 2 and sends usage information to the data warehouse.´
3. **Between 60 and 120 minutes**: Within 30 minutes of automatic charge 2, the client application sends a heartbeat to keep the session active.
4. **120 minutes**: Elastic Access makes automatic charge 3 and sends usage information to the data warehouse.
5. **140 minutes**: Twenty minutes after automatic charge 3, the client application wants to access item B in addition to item A. It therefore sends a regenerative access request for items A and item B.
Elastic Access immediately calculates a refund for the unused time for item A (40 minutes), and calculates the new combined charge for item A and item B. If the new combined charge can be covered by the available tokens, Elastic Access does the following:
  - Applies the refund and the new charge.
  - Starts a new timeline for automatic charges.
  - Sends relevant information to the data warehouse.


This concludes the original timeline.

If the new charge cannot be successfully applied, Elastic Access will follow the course of action determined by the **rollbackOnDeny** field in the request (see also "General Behavior for Session-Based Access Requests").

![PAS_SessionExMidSess-HTML.png](/assets/pas_sessionexmidsess-html.6110178ea7c4673ddafc29d30fc7edbf9f27c3c631f7bfefd5cc19a2cb704aca.9bb1daa4.png)