Subscriptions and recurring payments

Configure the amount, currency, frequency, renewal behavior, optional deferred first charge, and retry policy. Associate a customer and supported payment method with a plan; DEUNA then schedules the charges.

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

Keep your billing logic and use the DEUNA payment API for each collection. Your system remains responsible for calculating amounts, enforcing the agreement, scheduling collections, and preventing duplicates.

DEUNA can retain supported network transaction identifiers for later merchant-initiated transaction linkage. A vault token identifies stored card credentials; a network transaction identifier references transaction history. Neither replaces customer consent, and portability depends on the provider and network.

Use this model when an existing platform prepares scheduled collections as files. Agree with DEUNA on the batch format, secure delivery, token suitability, eligible processors, and per-payment result exchange before implementation.

Batch receipt is not payment approval, and authorization is not settlement. Reconcile every item to its final payment result.

• Recurring payment: a charge collected repeatedly under an agreement. The amount can be fixed, such as a membership, or variable, such as usage-based billing.
• Customer-initiated transaction (CIT): a payment the customer actively makes, including a first payment completed during sign-up.
• Merchant-initiated transaction (MIT): a later card payment your business initiates under the prior agreement without the customer actively participating in that payment.

Recurring describes the collection pattern; MIT describes who initiates a payment and under what authority. Saving a card alone does not authorize later charges.

For example, a customer can actively pay the first charge for a monthly membership as a CIT and authorize later renewals. A subsequent automatic renewal is an MIT. Setup can instead tokenize the card for a deferred first charge.

Retain an agreement that identifies your business and explains the amount or calculation, collection frequency or trigger, and cancellation terms. Capture and tokenize the card through a supported flow, with customer authentication where required.

Under the second Payment Services Directive (PSD2), qualifying MITs can fall outside strong customer authentication (SCA), but this is not a blanket exemption for recurring payments. Remote mandate setup requires SCA under the applicable conditions. See the EBA's MIT guidance and configure 3D Secure (3DS) where required.

If the amount can change, confirm which system calculates it and that the selected model supports those rules.

A plan defines the commercial and scheduling terms used by new subscriptions.

Supported billing intervals are DAILY, WEEKLY, BIWEEKLY, THIRTY_DAYS, SIXTY_DAYS, NINETY_DAYS, MONTHLY, BIMESTRIAL, QUARTERLY, ANNUAL, BIENNIAL, TRIANNUAL, and BIANNUAL.

A subscription connects a customer to a plan and records its lifecycle, payment method, billing dates, and processed transactions.

A plan can schedule the first charge instead of charging immediately. Choose one supported mode:

• Specific day of the month: charge on the configured calendar day. For example, a subscription created on October 3 with day 10 selected first charges on October 10.
• Number of days after acquisition: charge after the configured delay. For example, a subscription created on October 5 with a seven-day delay first charges on October 12.

The card is tokenized when the subscription is created even though billing starts later. The deferred-start rule applies to subscriptions created from that plan.

Configure retry behavior from the Subscription configuration tab in the Admin:

• maximum number of attempts;
• retry interval and its unit—minutes, hours, or days;
• linear or exponential backoff; and
• transition to paused or canceled after the configured attempts are exhausted.

The preview in the Admin shows the calculated attempt schedule before you save. Coordinate recovery ownership with any merchant-side retry process so the same invoice is not collected twice.

1. Open Subscriptions and select the Plans tab.
2. Select Create plan.
3. Enter the plan name, code, description, group, amount, currency, frequency, and renewal behavior.
4. Configure a deferred start if the first charge should occur later.
5. Review the settings and select Save plan.

Confirm that the saved plan is active and appears in the Plans list before assigning new subscriptions.

1. Open the Subscriptions tab.
2. Filter by customer email, creation date, plan, or status.
3. Open a subscription to review customer details, the associated plan, billing dates, amount, payment method, transactions, and lifecycle history.

Use transaction results—not the presence of a subscription row alone—to reconcile whether a charge succeeded.

Open the subscription, select Actions, and choose the required operation.

Add a reason when available to preserve operating context. A paused subscription can be resumed from the same Actions menu. After any action, verify the resulting status and effective date in the subscription details.