Subscriptions and recurring payments

DEUNA supports recurring payments through its own subscription engine, your existing billing system, or recurring batch uploads. This page explains the concepts behind recurring payments, helps you choose an approach, documents how the DEUNA subscription engine works, shows how to manage plans and subscriptions in the Admin, and lists what to validate before rollout.

Key concepts#

Recurring payments, MIT and CIT

Recurring payments collect charges repeatedly under an agreement with a customer. The amount can stay the same, such as a monthly membership, or change, such as a utility bill based on usage. Automatic collection lets customers pay later bills without manually completing each payment.

A merchant-initiated transaction (MIT) is a card payment your business initiates under a prior agreement, without the customer's active participation in that payment. A customer-initiated transaction (CIT) is a payment the customer actively makes, including when they choose to pay with a saved card.

Recurring describes the repeated collections. MIT describes who initiates a payment and under what authority. Automatic recurring card collections are a common use of MIT, but the terms are not interchangeable. Saving a card alone does not authorize future collections.

For example, a customer signs up for a hypothetical USD 10 monthly membership. They actively pay the first USD 10 at sign-up and agree to automatic monthly renewals. That sign-up payment is a CIT. The next month, your business collects the agreed renewal without the customer taking action: that payment is an MIT. Setup can also save a card for a deferred first charge instead of charging at sign-up.

Subscriptions, billing, and payment processing

• Subscription: the ongoing agreement between a customer and a product or service plan, including pricing and cancellation terms.
• Recurring payments: the charges collected under that agreement.
• Billing logic: decides what to charge and when.
• Payment processing: executes that instruction through a payment provider.

Choosing DEUNA for payment processing does not transfer every subscription-management responsibility to DEUNA. Customer policies, tax, invoices, and service delivery remain your responsibility unless separately integrated.

From setup to later collection

The setup and recovery flows on this page focus on recurring card payments.

1. Consent: obtain consent that identifies your business and explains the amount or calculation, collection frequency or trigger, and cancellation terms.
2. Card setup: capture and tokenize the card, with customer authentication where required. Setup can include an immediate payment or save the card for a deferred first charge.
3. Billing decision: the billing owner determines the amount and due date for each collection under the agreement.
4. Processing: DEUNA processes the payment.
5. Reconciliation: reconcile each result to your records.

DEUNAFlow diagramExpand

This lifecycle is conceptual. Your chosen approach determines which system schedules or submits later collections.

Recognize your payment scenario#

For variable bills, identify which system calculates the amount and confirm that your chosen approach supports those billing rules. Both scenarios require prior agreement and a supported payment configuration.

Choose a DEUNA approach#

Choose based on where your billing decisions belong and how your system supplies collection instructions.

DEUNA subscription engine

Configure billing amounts, currencies, frequencies, automatic renewal, and retry rules. Associate customers and payment methods with subscriptions so the engine can schedule and process charges. See How the DEUNA subscription engine works below and Manage plans and subscriptions from the Admin for supported configuration, including deferred first charges.

The engine and its recurring-payment classification must be enabled for the required merchant and store. Processor support, token portability, network-transaction linkage, and authentication requirements can limit which connections are eligible for later charges.

Merchant subscription engine

Keep your billing logic and use the DEUNA payment API for collection. DEUNA supplies routing, eligible cross-provider retries, and payment handling for MIT and PSD2 flows, including initial 3DS where required. Configure payment strategies for supported connections.

DEUNA also stores network transaction identifiers (NTIDs) for subsequent MIT linkage. A vault token identifies stored card credentials; an NTID references network transaction history. Neither replaces customer consent, and supported linkage depends on the provider and network.

Recurring batch upload

DEUNA can submit token-based batch collections for online processor authorization where supported. A batch changes how instructions arrive; authorization can still occur online for each payment.

Agree on the recurring batch format, delivery, token suitability, processors, and per-payment result exchange with DEUNA before integration.

How the DEUNA subscription engine works#

The Subscriptions API manages customer subscriptions to the plans you offer. Use it to control subscription and plan states and to ensure that billing, activation, cancellation, and expiration are performed correctly.

You can also create plans and manage subscriptions from the Subscriptions module in the Admin. See Manage plans and subscriptions from the Admin for the step-by-step guide.

Data model

Deferred start

A plan can define when the first charge occurs instead of charging immediately, either on a specific day of the month or a set number of days after the subscription is created. Only one deferred start mode can be configured per plan.

• No immediate charge is made
• Charges are scheduled automatically according to the plan configuration, without additional API calls.
• Plan editing is not supported, and deferred start cannot be changed once the plan has active subscriptions.

See Create a plan with deferred start for the Admin configuration steps and examples.

Supported billing intervals

Plan states

Subscription states

Expand

Manage subscriptions with the API

Create a subscription

Use the Create a subscription endpoint.

List subscriptions

Use the Get subscription list endpoint to receive all subscriptions for a customer.

Update a subscription or payment card

If the customer updates their card, you can:

• Call Update subscription to update the subscription.
• Retry the charge for the overdue invoice.

Capture replacement cards through secure card capture so raw card data stays out of your systems.

Cancel a subscription

Cancellation changes the status to canceled. You can specify:

• Cancellation at the end of the current billing cycle.
• Cancellation at the end of the renewal cycle. For example, a monthly subscription renewed for one year is canceled when that year is completed.
• term_end: indicates the end of the current cycle and generates a refund.
• bill_date: indicates the start of the next cycle (24 hours after term_end) and generates a refund.

For the matching Admin steps, see Cancel a subscription in the Admin.

Automatic retries

The subscription engine includes a retry mechanism to handle temporary failures, such as communication problems with payment processors during subscription charging or activation. It ensures that payment and activation complete without manual intervention, even with intermittent failures.

• Automatic retry: if subscription charging or activation fails, the system attempts the process again after a delay.
• Exponential backoff: each retry increases the wait time between attempts to avoid overloading the system.
• Retry limit: when retries reach a configurable maximum (for example, six attempts), the system marks the subscription as paused or cancel (based on your own configuration)
• Notification: after failed attempts, the system can notify the customer or administrator about the subscription status and the failures.

Manage plans and subscriptions from the Admin#

Plans define the billing conditions of a subscription, including its price, frequency, renewal type, and optionally a deferred start date for charging. You manage both plans and customer subscriptions from the Subscriptions module in the Admin.

Plan fields

Create a plan with deferred start

1. In the sidebar menu, go to Subscriptions.
2. In Subscriptions, click Plans.
3. Click Create plan.
4. Complete the plan's general fields: name, description, amount, currency, frequency, and renewal.
5. In the Deferred start section, enable the "Schedule billing start" toggle.
6. Select how you want to define the billing start:

   • On a specific day of the month: the charge will occur on the same day every month, regardless of when the subscription was created.

     Example: if you select day 10 and the user subscribes on October 3, the first charge will be on October 10.

   • X days after acquiring the plan: the charge will occur X days after the subscription is created.

     Example: if you choose 7 days and the subscription starts on October 5, the subscription start period will be October 12.

7. Save the changes by clicking Save plan.

The deferred start will be recorded and applied to all subscriptions created with this plan.

View subscriptions

Access the Subscriptions tab within the module.

You can filter subscriptions by customer email, creation date, or plan name.

Subscription details

Click on any subscription in the list to access its detailed view.

Cancel a subscription in the Admin

1. Go to the Subscriptions section in the sidebar menu.
2. In the Subscriptions tab, search for the customer by email or ID.
3. Click the action menu icon ··· and select View subscription.
4. In the detail view, click the Actions button and select Cancel.
5. A modal will open with the option to select a Cancellation policy. There are three options:

6. If you choose the specific date option, select the day on the calendar.
7. (Optional) Add a cancellation reason to maintain traceability.
8. Click Confirm cancellation to execute the action.

Pause a subscription

1. In the subscription detail, click the Actions button and select Pause.
2. A modal will appear where you can choose the Pause policy. There are three options:

3. If you choose the specific date option, select the day on the calendar.
4. (Optional) Enter a pause reason if you want to record context.
5. Click Confirm pause to apply the action.

Benefits for recurring collections#

Retry timing informed by behavior

DEUNA's AI-driven retries learn from historical merchant and customer behavior to select timing for eligible recovery attempts. Compared with a fixed retry schedule, this can target a time when a recoverable condition may have changed. For example, a later attempt may succeed after an insufficient balance is replenished.

The aim is to recover revenue and reduce involuntary churn: customers lost because payments fail. Approval is not guaranteed. Confirm available recovery features and provider or network limits for your chosen approach.

Resilience through multiple providers

Routing through configured eligible providers reduces dependence on a single processing connection. Default processing can use a second processor in a fallback cascade. Eligibility depends on the failure, provider rules, and token suitability for the alternate route. Changing providers does not replenish an insufficient balance.

If a collection has no confirmed success, first distinguish an unresolved outcome from a result that permits recovery:

DEUNAFlow diagramExpand

Each recovery path depends on the agreement, provider rules, and supported configuration:

• Use a supported customer flow only if permitted. Required customer authentication must return the customer to the supported flow; unattended retries cannot replace it.
• Provider fallback requires a configured eligible provider.
• A later collection retry must be eligible and occur at the selected time.
• Technical retries after communication failures follow documented rules for the original payment.

Coordinate recovery ownership between your system and DEUNA to prevent independent processes from collecting the same bill twice.

Less sensitive card data in your systems

Use DEUNA's card capture and Payment Vault to tokenize credentials and keep raw card data out of your systems. This can reduce applicable controls under the Payment Card Industry Data Security Standard (PCI DSS). Outsourcing still leaves merchant responsibilities, including provider oversight and compliance validation. See PCI SSC outsourcing guidance.

Prepare for adoption#

Confirm the billing owner, consent flow, supported providers, token suitability, and recovery policy. If a card becomes unusable, ask the customer to replace it through secure card capture.

For uncertain outcomes, reconcile the original payment before starting a new collection. Follow the idempotent request guidance for technical retries after communication failures. Use documented result channels, including webhooks where applicable, to update your records.

Cancellation handling

Distinguish a cancellation request from its effective time: immediate, end of period, or a specified date under the configured policy.

• Stop new submissions from that time, or earlier if charging authority is revoked or expires.
• Remove affected unsubmitted collections from the scheduling system.
• Reconcile payments already submitted. Do not assume cancellation stops an in-flight payment; confirm any reversal or refund under the applicable policy.

Validate before rollout

Use supported sandbox cases. Coordinate unavailable cases with DEUNA before rollout.

• Setup: confirm retained consent, a suitable token, and completion of required authentication.
• Collection: verify that the amount matches the billing decision and that each result reconciles to your records.
• Recovery: exercise eligible recovery and authentication-required outcomes. Confirm the agreed policy and customer-action flow.
• Uncertain result: verify reconciliation before another collection attempt.
• Cancellation: check the effective-time policy, revoked consent, removal of affected queued collections, and reconciliation of submitted payments.

Next steps#

• DEUNA subscription engine: configure your plans from the Admin and integrate the Subscriptions API.
• Merchant subscription engine: integrate the DEUNA payment API and configure payment strategies.
• Recurring batch upload: agree on collection and result exchange with DEUNA before building the integration.