Glomo supports two bulk subscription actions from the Dashboard, both built on the same batch upload, validation, and confirmation lifecycle:

- **Bulk Subscription Charges** — initiate charges across many As Presented subscriptions in a single operation.
- **Bulk Update Next Payment Date** — shift the upcoming billing date for many active Fixed-Frequency subscriptions in a single operation.


## Bulk Subscription Charges

Bulk charging allows you to initiate charges across multiple As Presented subscriptions in a single operation — directly from the Glomo Dashboard. Instead of calling the Create Payment API once per subscriber, upload a structured file containing all charge details and Glomo will process them in the background.

### How It Works

> Glomo does not initiate any charges until you explicitly confirm after reviewing the validation summary.


### File Format & Template

Your bulk charge file must follow the Glomo-provided template, available to download directly from the Bulk Subscription Charges page. Upload your file in **CSV** or **Excel (.xlsx)** format only.

| Column | Required | Description |
|  --- | --- | --- |
| `subscription_id` | Yes | ID of the active As Presented subscription to charge (e.g. `sub_12345`) |
| `amount` | Yes | Charge amount in **major currency units** with up to 2 decimal places (e.g. `1000.00` for one thousand dollars, `10.50` for ten dollars and fifty cents). Must be greater than zero. |
| `currency` | Yes | 3-letter ISO 4217 currency code (e.g. `USD`). Must match the subscription plan's currency. |
| `merchant_reference` | Yes | Your reference for this charge, used for idempotency and reconciliation. **Each reference can only be used once** across all your bulk uploads (any action). The only exception: if a previous row failed validation, you can reuse its reference. References that match an existing payment are also rejected. |
| `reference_number` | No | An optional secondary reference for your own reconciliation (e.g. an invoice number or PO number). Glomo carries it through to the validation summary and results file but does not use it for processing or duplicate checks. |


Each row represents a single charge request. Your file must not exceed **1,000 rows** or **10 MB**.

### Subscription Validation Rules

During the asynchronous validation phase, each row is checked against the following business rules. Rows that fail any of these checks are marked as  Validation Failed  and will not be charged.

- The `subscription_id` must exist and belong to your business.
- The subscription must have an associated subscription plan.
- The subscription must be an **As Presented** type.
- The subscription must be in an  Active  or  Authorized  state.
- The subscription must have at least one **successful prior payment using a Card payment method**. This is required to process subsequent card payments.
- The `amount` must not exceed the subscription plan's configured `max_amount`.
- The `currency` must match the subscription plan's currency.
- The `merchant_reference` must be unique across all your bulk uploads (any action) and must not match any existing payment. References from rows that previously failed validation can be reused.


### Batch States

Once you upload a file, a batch is created and persists through the entire processing lifecycle. You can track its progress from the batch table at any time.

| State | Description |
|  --- | --- |
|  Created  | The batch has been created and the uploaded file is being ingested. |
|  Validation In Progress  | File format checks have passed. Individual rows are being validated against business rules in the background. |
|  Awaiting Confirmation  | All rows have been validated. Review the validation summary — then confirm to proceed or cancel to discard. |
|  In Progress  | You have confirmed. Charges are being initiated — you can leave the page and check back. |
|  Completed  | All charges have been attempted. Download your results file from the batch detail page. |
|  Failed  | The batch could not be processed. This can occur if the file has invalid headers, contains no valid rows after validation, or if a processing error prevents completion. The failure reason is displayed on the batch detail page. |
|  Cancelled  | You cancelled the batch after reviewing the validation summary. No charges were initiated. |


#### Row States

Each individual row within a batch also has its own state:

| State | Description |
|  --- | --- |
|  Created  | The row has been parsed from the file. |
|  Validation In Progress  | The row is being validated against business rules. |
|  Validated  | The row passed all validation checks and is ready for processing. |
|  In Progress  | A charge is being initiated for this row. |
|  Success  | The charge was successfully initiated. |
|  Validation Failed  | The row failed one or more validation checks. See the error details for the specific reason. |
|  Processing Failed  | The charge could not be initiated. See the error details for the specific reason. |


### Cancellation

After validation completes and the batch is in  Awaiting Confirmation  status, you can choose to **cancel** the batch instead of confirming it. Cancelling moves the batch to the  Cancelled  state and ensures no charges are initiated. Once a batch has been confirmed and is  In Progress , it cannot be cancelled.

### Results & Reconciliation

Once your batch reaches  Completed  status, download the results file from the batch detail page. The file contains the following columns for every row you submitted:

| Column | Description |
|  --- | --- |
| `row_number` | The row's position in the original uploaded file. |
| `merchant_reference` | The reference you provided for reconciliation. |
| `payment_id` | The Glomo payment ID for the charge, if successfully initiated. |
| `subscription_id` | The subscription that was charged. |
| `amount` | The charge amount in the currency's major units. |
| `reference_number` | The optional secondary reference you provided in the upload, passed through unchanged. |
| `status` | The payment status if the charge was initiated, or the row's failure status otherwise. |
| `error_message` | The payment-level error message if the charge failed after initiation, or the validation/processing error otherwise. |


### Webhooks

All charges trigger the existing `payment_success` and `payment_failed` webhooks. A `batch_id` field is included as a **top-level field** in each webhook payload for payments initiated via batch processing, so you can group outcomes by upload in your own systems.

## Bulk Update Next Payment Date

Bulk Update Next Payment Date allows you to shift the upcoming billing date for many active Fixed-Frequency subscriptions in a single operation — directly from the Glomo Dashboard. Instead of calling the Update Next Payment Date API once per subscription, upload a structured file with all the changes and Glomo will apply them in the background.

This is particularly useful for insurance and financial-services merchants who need to align recurring billing dates with policy issuance, renewal cycles, or batch onboarding events without cancelling and recreating each subscription.

For the equivalent single-subscription flow (dashboard and `PATCH /subscriptions/{subscription_id}/next-payment-date` API), see [Subscription Management](/product-guide/payin/subscriptions/subscription-management).

### How It Works

> Glomo does not change any subscription's next payment date until you explicitly confirm after reviewing the validation summary.


### File Format & Template

Your bulk update file must follow the Glomo-provided template, available to download directly from the Bulk Update Next Payment Date page. Upload your file in **CSV** or **Excel (.xlsx)** format only. Each file may contain a maximum of **1,000 rows**.

| Column | Required | Description |
|  --- | --- | --- |
| `subscription_id` | Yes | The unique identifier of the Fixed-Frequency subscription whose next payment date you want to update (e.g. `sub_5JU9yv0lGSUP`). Must belong to your business. |
| `next_payment_date` | Yes | The new next payment date in **`YYYY-MM-DD`** format (ISO 8601). Can be moved earlier without limit, but can only be deferred up to **28 days** from the subscription's current `next_payment_date`. |
| `merchant_reference` | Yes | Your reference for this update, used for reconciliation. **Each reference can only be used once** across all your bulk uploads (any action). The only exception: if a previous row failed validation, you can reuse its reference. |


Sample row:

| `subscription_id` | `next_payment_date` | `merchant_reference` |
|  --- | --- | --- |
| `sub_12345` | `2026-05-01` | `REF-001` |


### Subscription Validation Rules

During the asynchronous validation phase, each row is checked against the following business rules. Rows that fail any of these checks are marked as  Validation Failed  and will not be processed.

- The `subscription_id` must exist and belong to your business.
- The subscription must be a **Fixed-Frequency** subscription. As Presented subscriptions are rejected.
- The subscription must currently be in the  Active  state. Subscriptions in `created`, `paused`, `halted`, `cancelled`, `failed`, `expired`, `completed`, or `authorized` are rejected.
- The subscription must have **no in-flight payment attempt**. If a payment is currently being processed, the row is rejected to avoid races between the payment and the date change.
- The subscription must already have a `next_payment_date` set — i.e. it cannot be a brand-new subscription that has never billed yet, since there must be an existing schedule to shift.
- The new `next_payment_date` may be moved **earlier without limit**, but may only be **deferred up to 28 days** from the subscription's current `next_payment_date`.
- The `subscription_id` must not appear more than once in the same uploaded file.
- The `merchant_reference` must be unique across all your bulk uploads (any action). References from rows that previously failed validation can be reused.


> Tip: because the 28-day cap is measured against the **current** `next_payment_date`, you can chain multiple bulk updates over time to defer further — each subsequent update is bounded by the most recent next payment date.


### What Happens on a Successful Update

When a row is processed successfully, Glomo applies the following changes to the subscription:

- The subscription's `next_payment_date` is set to the value you provided.
- If the subscription has an `end_date`, it is shifted by the **same number of days** as the change to `next_payment_date`, so that the total number of remaining billing cycles is preserved. This applies whether the date is deferred or pulled earlier.
- The internal billing anchor used to compute subsequent payment dates is reset to the new `next_payment_date`. All future scheduled charges flow from this new anchor.


### Batch States

The batch and row state machines are identical to Bulk Subscription Charges — see the [Batch States](#batch-states) and [Row States](#row-states) tables above. The only differences are:

- **In Progress** means subscription updates are being applied (rather than charges being initiated).
- **Completed** means all updates have been attempted (rather than all charges).
- **Cancelled** means no subscriptions were updated (rather than no charges initiated).


### Cancellation

After validation completes and the batch is in  Awaiting Confirmation  status, you can choose to **cancel** the batch instead of confirming it. Cancelling moves the batch to the  Cancelled  state and ensures no subscriptions are updated. Once a batch has been confirmed and is  In Progress , it cannot be cancelled.

### Results & Reconciliation

Once your batch reaches  Completed  status, download the results file from the batch detail page. The file contains the following columns for every row you submitted:

| Column | Description |
|  --- | --- |
| `row_number` | The row's position in the original uploaded file. |
| `merchant_reference` | The reference you provided for reconciliation. |
| `subscription_id` | The subscription targeted by the row. |
| `old_next_payment_date` | The subscription's `next_payment_date` immediately before the update. Only populated for successful rows. |
| `new_next_payment_date` | The new `next_payment_date` written to the subscription. Only populated for successful rows. |
| `status` | The row's final status (`success`, `validation_failed`, or `processing_failed`). |
| `error_message` | The validation or processing error message for failed rows. Empty for successful rows. |


### Webhooks

For each subscription whose date is successfully updated, Glomo fires a **`subscription`** webhook with `event_type: "updated"`. The webhook payload is the standard `Subscription` resource and reflects the new `next_payment_date`.

> Note: unlike Bulk Subscription Charges, the subscription `updated` webhook does **not** include a `batch_id` field. If you need to correlate webhook deliveries back to a specific bulk upload, use the `merchant_reference` you supplied in the file together with the results file.


If a row fails validation or processing, no subscription is mutated and no webhook is sent for that row.

### What this feature does **not** do

- It will not change subscription frequency (e.g. monthly → quarterly).
- It will not modify the subscription amount or currency.
- It is not a retry mechanism for failed payments — use the standard subscription retry/recovery flow.
- It does not apply to As Presented subscriptions.