Subscription processing, payments and renewals

The subscription payment daily processing job

Subscription renewals are processed according to the configuration of the subscription product (explained in the Subscription products), in conjunction with the conditions detected when the daily processing job runs.

The job picks up all the subscription actions to be carried out, when all these conditions are met:

• Skip Processing is unchecked
• Next Billing Date is today or in the past
• Start Date is today or in the past
• End Date is blank or in the future
• Cancelled Date is blank or in the future
• Suspended Date is blank or in the future
• Last Processed At is blank or before today

A subscription is not processed if any of these conditions are met:

• Skip Processing is checked
• Next Billing Date is in the future
• Start Date is in the future
• End Date is in the past
• Cancelled Date is in the past
• Suspended Date is in the past
• Last Processed At is today, because it has already been processed once today
• One-time subscription is fully paid

Subscription fields the job updates

Every subscription that is due is validated before anything is charged. On every run the job writes Last Validation At, Validation Status, and Validation Error Messages, whether or not the record passes. A subscription that fails validation, for example one with a blank Term Price or no Contact, is skipped and not charged until the record is fixed.

Every subscription that goes on to be processed gets Last Processed At set to the current time. This is what stops a subscription from being charged twice on the same day.

When the payment succeeds, the job updates these fields on the Subscription record:

• Next Renewal Date — advances by one term (Term Length and Term Unit) from its previous value, calculated in the store’s timezone. It is not reset to the day the payment was taken, so a late or retried payment does not shift the billing cycle.
• Next Billing Date — the new Next Renewal Date plus the billing delay (Billing Delay Length and Billing Delay Unit).
• Renewal Order Date — the new Next Renewal Date minus the product’s Renewal Order Days. If that date has already passed, it is set to the start of tomorrow. Evergreen subscriptions only.
• Delinquent Date, Delinquent Reason, and Delinquent Order — cleared.
• Renewal Order — cleared on an evergreen subscription when the order paid was the renewal order. If the payment cleared a delinquent order instead, the renewal order stays linked so the next installment can still be paid against it.

The same update runs when no card is charged, either because Charge Payments is unchecked or because the renewal order has already been paid in full, for example through the order payment link.

When the payment fails, none of the dates advance. The job writes these fields instead:

• Delinquent Date — the time of the first failure. Retries do not change it.
• Delinquent Order — the order the payment was attempted against.
• Delinquent Reason — the time and the payment gateway’s message, added above any earlier entries so the field reads as a log with the newest failure first.

The job retries the payment 1, 2, 3, 5, and 8 days after the Delinquent Date. If the day 8 retry also fails, it writes Suspended Date and stops processing the subscription. See Manage delinquent subscription payments.

The job never changes the payment token, Payment Provider, or Term Price on the subscription.

Orders and payments the job creates

For an evergreen subscription, the charge is recorded against an Order:

• If a renewal order already exists, or the subscription is delinquent, the job pays that existing order. See Subscription renewal orders.
• Otherwise it creates a new Order with Checkout Step payment, linked to the original purchase through Original Subscription Order. The billing and shipping addresses, shipping method, and store are copied from the original order, not from the account or contact.
• It adds one Order Product per subscription, priced at the subscription’s Term Price, with tax calculated from the copied address.
• When the payment succeeds, Checkout Step moves to payment-finalized, and about 30 seconds later to complete. Order integrations and any Flows that trigger on completed orders run at that point. When the payment fails, it moves to failed.

For a fixed-term (one-time) subscription, no new order is created. Each payment is attached to the original order, and that order’s Checkout Step does not change. Processing stops once the payments on the subscription add up to its Full Price.

For both types, a charge creates these records:

• A Payment on the order with Origin SU01 (evergreen) or SU02 (fixed-term), the amount, the gateway transaction number, the payment status, and the paid time. A declined charge also creates a Payment with a failed status and the gateway response, so the attempt is visible in Salesforce. See Payment origin codes.
• One Payment Item per order product on a successful payment, splitting the payment amount across the items.
• A link from the Payment to the customer’s saved Payment Method, when the card used matches one on file.

If the order includes a membership product and is fully paid, the job also sets Membership on the customer’s Account.

Job date changes for monthly subscription payments

For monthly payments, if a billing date is 31st and the following month there are only 30 days, the billing date will move to the 30th from that point on. When it gets to February, the billing date will become 28th (29th on a leap year) and will continue as the 28th of the month moving forward.

Default options for payment processing

• Skip Processing is left unchecked when the subscription is created. Check it to stop the subscription from being processed on its Next Billing Date.
• Charge Payments is set from the product’s subscription behavior at the time the subscription was created. It determines whether the job debits the customer’s card on the Next Billing Date, or advances the subscription to the next period without taking payment. Either way the subscription is processed and, for an evergreen subscription, the order is created.

What Charge Payments controls

Charge Payments decides only whether the daily job calls the payment gateway. It does not decide whether the subscription is processed.

:::warning Unchecking Charge Payments does not pause a subscription. The job still advances the dates and, for an evergreen subscription, still creates an Order and marks it complete with nothing paid against it. To stop processing, check Skip Processing or set an End Date, Cancelled Date, or Suspended Date. :::

When it is unchecked, the job processes the subscription as if it had been paid:

• Next Renewal Date, Next Billing Date, and Renewal Order Date advance as described above, and any delinquent fields are cleared.
• For an evergreen subscription, an Order is created, or the existing renewal order is used, and its Checkout Step moves to complete.
• No Payment record is created and the gateway is not called. The order’s balance stays outstanding until you record a payment yourself.
• The subscription does not need a payment token, so it passes validation without one.

When it is checked, the subscription must have a Payment Provider that supports recurring payments. A subscription with Charge Payments checked and no Payment Provider fails validation and is skipped on every run. One whose provider does not support recurring payments is reported as an error and not charged.

Two things override the checkbox. A customer paying from their subscription page on the store is always charged, whether or not it is checked. StoreConnect also recalculates the value from the product’s Subscription Behavior and the provider’s recurring support whenever it links a payment source to the subscription: at checkout, when a Salesforce payment is processed against the original order, on an additional order payment, and from POS. If you uncheck it by hand, a later payment on the original order can check it again.

To turn a subscription into one you invoice and collect outside StoreConnect, uncheck Charge Payments and record each payment against the order the job creates. See Subscription products for how each behavior sets the initial value.

Subscription term price

The Term Price is the price for the subscription, and is set automatically when a subscription product is purchased. Changing the Term Price will change the amount the customer is charged when the subscription is next processed. The term price (whatever it is set at) is the amount charged each time the subscription process runs.

The subscription is always charged in the same currency it is first set up with.

Subscription payment origin

StoreConnect sets an Origin field (s_c__origin__c) on every Payment record to identify how and where the payment was created. This is useful for building Flows and automations that behave differently depending on the payment source — for example, triggering logic only when a renewal charge has been initiated by StoreConnect’s subscription job.

For the full list of origin codes, see Payment origin codes.

Subscription payment token

StoreConnect stores a payment token on every subscription that is set up for automatic charging. This token is a reference to the customer’s saved payment profile on the payment gateway (for example, a customer profile ID in Authorize.Net, a TokenCustomerID in eWay, or a payment method ID in Stripe). It allows StoreConnect to charge the customer’s card on future renewal dates without requiring them to re-enter their payment details.

When the token is added

The token is set the first time a subscription is associated with a successful payment:

Scenario	Payment origin	Notes
Customer purchases a subscription at checkout	WS01 — Website Subscription	The gateway returns the token as part of the payment response; it is stored on the subscription immediately
A Salesforce-initiated payment is processed against an order that has subscription items	SF01 — Salesforce Payment	The subscription record may already exist in Salesforce without payment source details; StoreConnect backfills the token (and payment provider) from the payment response when they are missing

When the token is swapped

The token is replaced when a customer updates their payment method:

• Customer updates payment details — when a customer submits new card details via the Update Payment Details page in their account, the gateway processes the update and returns a new token, which replaces the existing one on the subscription
• 3D Secure callback — if the payment update requires 3DS authentication, the token is rotated to the new value once the authentication callback completes successfully

When the token is not updated

The token is not changed during regular subscription processing. Recurring charges (SU01 — Automatic Subscription Payment Evergreen, SU02 — Automatic Subscription Payment Fixed-term), renewals, delinquent payment retries, cancellations, and expirations all reuse the existing token without modification.

Shared tokens across multiple subscriptions

If a customer has more than one active subscription, all subscriptions share the same gateway customer profile. Updating the payment method on one subscription effectively updates the saved payment method for all of that customer’s subscriptions.

Troubleshoot subscriptions and renewals

Issue	Solution
Customer not charged on renewal date	Check subscription status (active/paused). Verify payment method on file. Manually trigger charge if confirmed.
Duplicate renewal charge	Issue refund (see Issuing Refunds section). Update next billing date to prevent duplicate.
Payment declined	Contact customer, request updated payment method. Manually retry charge once updated.
Customer wants to cancel after renewal	Process refund first, then cancel subscription separately.
Prorated charge needed	Use Manual Charge with custom amount. Document reason in notes.