Skip to main content
The Autopay endpoints are in Beta. Feedback from the community is welcome. Synctera may make breaking changes to these endpoints.

​
Overview

Autopay removes the need for your customers to remember to pay their credit balance each month. You create a single autopay configuration on a lending account that answers three questions:
  • How much? — minimum due, statement balance, current balance, or a fixed amount
  • When? — on the due date, a set number of days before the due date, or daily
  • From where? — an internal Synctera account, or an external bank account debited via ACH
Once a configuration is active, Synctera generates an autopay record for each upcoming payment, recalculates the amount as balances change, executes the payment on the scheduled date, and records the outcome. Autopay is built on two distinct resources. Keeping them straight is the key to using the API:
You never create an autopay record directly. Synctera creates one for each billing cycle (for STATEMENT autopays) or on a recurring cadence (for SCHEDULED autopays), based on the active configuration.

​
Prerequisites

Before you create an autopay configuration, make sure the following are in place.
1

A lending account

Autopay applies to lending accounts — line of credit, secured charge, or unsecured charge. See Line of Credit Accounts, Secured Charge Accounts, or Unsecured Charge Accounts.You will need the lending_account_id.
2

A customer with an ownership relationship

Every autopay configuration is owned by a customer — either a person (person_id) or a business (business_id). Exactly one must be provided.That customer must hold one of the following relationships with the lending account:
  • PRIMARY_ACCOUNT_HOLDER
  • ACCOUNT_HOLDER
  • JOINT_ACCOUNT_HOLDER
This means a joint or non-primary account holder can set up autopay, not just the primary holder.
3

A funded payment source

For INTERNAL_TRANSFER, you need the source_account_id of a Synctera platform account. The owning customer must hold one of the three ownership relationships above with that account too.For ACH, you need the external_account_id of a linked external account. The external account must be verified and must be owned by the same customer, and you must have the customer’s authorization to originate an outgoing ACH debit. See External Accounts.
4

Statements enabled (for STATEMENT autopays)

STATEMENT autopays are triggered when a statement is generated for the billing cycle. The account must be producing statements with a minimum payment due and a payment due date. See Statements.
5

API credentials

A valid API key for the Sandbox or Production environment. See Dev Setup.

​
Key concepts

​
Autopay type

autopay_type controls what triggers an autopay. It also constrains which amount and timing rules are valid. STATEMENT is the typical credit card or line of credit use case: pay the bill each cycle. SCHEDULED is a sweep: pay down whatever is outstanding, every day.

​
Amount rules

amount_rule determines how much each payment is for.
FIXED_AMOUNT never overpays. Synctera pays the lesser of the fixed amount and the current balance.
If the calculated amount is 0 — the balance is already paid off, for example — the autopay is skipped rather than executed, and its status becomes SKIPPED.

​
Timing rules

timing_rule determines when the payment is initiated.
ACH needs lead time. An outgoing ACH debit takes one to three business days to settle, so ON_DUE_DATE combined with ACH risks a late payment. For ACH payment sources, use DAYS_BEFORE_DUE with an offset_days of 3 to 5.

​
Payment method

payment_method determines how funds are moved, and which sub-object of payment_configs you must populate. The ach config also accepts two optional fields:
  • sec_code — Standard Entry Class code: WEB (default), CCD, or PPD
  • is_same_day — send as same-day ACH; defaults to false
The internal_transfer config accepts an optional subtype that sets the transaction subtype; it defaults to auto_payment.

​
Rule configs and payment configs

rule_configs and payment_configs are containers holding rule-specific and method-specific settings. You only populate the sub-object that matches the rule or method you selected. For example, an autopay using DAYS_BEFORE_DUE and ACH populates rule_configs.days_before_due and payment_configs.ach, and leaves the rest out. An autopay using STATEMENT_BALANCE and ON_DUE_DATE may omit rule_configs entirely, since neither rule takes parameters.

​
Description template

description_template is an optional Go template that produces the ACH addenda record or the internal transfer memo. It supports these variables: The template is rendered when the autopay record is created and stored on that record as rendered_description. The default is Autopay.

​
Failure policy

failure_policy is required, and currently accepts a single value: NO_RETRY. A failed payment is not retried automatically. Configurable retry policies are planned but not yet available.
There are no autopay-specific webhook events today. To detect a failed payment, poll GET /v2/autopays filtered by status=FAILED, and inspect attempt_history for the reason.

​
Statuses

An autopay configuration has a status: An autopay record has its own status:

​
Amounts on an autopay record

Two fields carry the amount, and they mean different things:
  • current_amount — for a PENDING autopay, the projected amount, recomputed on every read from the config snapshot and current balances. It changes as the customer makes payments, receives refunds, or adds charges. For an EXECUTED autopay it mirrors executed_amount. For SKIPPED or FAILED autopays with no execution it is 0.
  • executed_amount — the amount actually used at execution. Absent until the autopay executes; once set, it is the source of truth and never changes.
Because current_amount is recalculated on read, it is what you should display in your UI for an upcoming payment — alongside a note such as “This amount may change if you make payments or receive refunds before the scheduled date.”

​
Config snapshot and attempt history

Each autopay record carries a config_snapshot — a copy of the configuration as it stood when the record was created. Editing the configuration later does not retroactively change an already-created autopay. attempt_history.attempts lists each execution attempt chronologically, with attempted_at, a status of SUCCESS, FAILED, or SKIPPED, an optional reason, and payment_attributes identifying the resulting payment (transaction_id for an internal transfer, ach_id for an ACH debit).

​
API workflow

1

Create the autopay configuration

POST /v2/autopay_configs creates the rule. Only one active configuration can exist per lending account; a second attempt returns 409.This example pays the full statement balance three days before the due date, from the customer’s own deposit account on the platform.
A 201 response returns the configuration with its id and a status of ACTIVE:
To pay the minimum due from an external bank account instead, swap the payment method and give ACH enough lead time:
2

Let Synctera create the autopay records

You do not create autopays. For a STATEMENT configuration, when a statement is generated Synctera creates an autopay with:
  • scheduled_date — the due date, minus offset_days if you used DAYS_BEFORE_DUE
  • status — PENDING
  • config_snapshot — a copy of the rule as it stands now
  • statement_id and billing_period_id — the statement this autopay pays
  • rendered_description — your description template, rendered
For a SCHEDULED configuration, autopays are created during end-of-day orchestration and have no billing_period_id.
3

Show the customer their upcoming payment

List autopays for the account with GET /v2/autopays, or fetch one with GET /v2/autopays/{autopay_id}.
Useful filters include lending_account_id, autopay_config_id, status, statement_id, billing_period_id, scheduled_date (or the from_scheduled_date / to_scheduled_date range), and from_executed_amount / to_executed_amount.
4

Check the outcome after execution

On the scheduled date Synctera recomputes the amount and acts:
  • Amount greater than 0 and payment succeeds → status becomes EXECUTED, executed_amount is set, and payment_attributes carries the transaction_id or ach_id
  • Amount is 0 → status becomes SKIPPED
  • Payment fails → status becomes FAILED, and attempt_history records the reason
Poll GET /v2/autopays with status=FAILED to find payments that need attention. Because the only failure policy today is NO_RETRY, a failed autopay is not retried — the customer must make a manual payment.
5

Cancel a single upcoming payment

To skip one scheduled payment without touching the underlying rule, use PATCH /v2/autopays/{autopay_id} to set its status to SKIPPED. This is the only update the endpoint supports, and it only applies to a PENDING autopay.
Cancel before the payment is initiated. If the ACH debit has already gone out, cancelling the autopay record does not recall it — that payment will post as scheduled. Tell the customer that cancelling applies to payments not yet initiated.
6

Update or pause the configuration

PATCH /v2/autopay_configs/{autopay_config_id} updates the config, the status, or both — for example to change the payment source, switch the amount rule, or pause autopay.
Because each autopay record holds a config_snapshot, an edit does not change an autopay that has already been created. If a payment for the current cycle has already been initiated, the edit takes effect starting with the next cycle — surface that to the customer rather than letting them assume this month’s payment changed.
7

Delete the configuration

DELETE /v2/autopay_configs/{autopay_config_id} removes the rule and returns 204. Use this when the customer turns autopay off for good; use PAUSED when they may turn it back on.
An account relationship cannot be deleted while an active autopay configuration depends on it. Delete or repoint the autopay configuration first.

​
Validation rules

The API rejects a configuration with 400 when these constraints are not met:

​
Things to watch for

Avoid double payments. If a payment has been initiated but has not yet posted, a second payment can overdraw the customer. Check for a PENDING or recently EXECUTED autopay before initiating a manual payment for the same cycle. ACH settles on its own schedule. An outgoing ACH debit is initiated on the scheduled date but posts one to three business days later. The balance and any days-past-due calculation only change on the posting date. Build in lead time with offset_days rather than relying on the due date. The projected amount moves. current_amount on a PENDING autopay is recomputed on every read. A manual payment or a posted refund lowers it; new charges can raise it when the rule is CURRENT_BALANCE. Read it fresh rather than caching it. Failures are terminal for that cycle. With NO_RETRY as the only failure policy, a failed autopay stays failed. Detect it by polling and prompt the customer to pay manually or fix their payment source.

​
Reference