> ## Documentation Index
> Fetch the complete documentation index at: https://docs.synctera.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Revolving Credit Card
> A credit line where cardholders can carry a balance from one billing cycle to the next, paying interest on the unpaid amount. Revenue comes from interest and fees rather than interchange alone.
A revolving credit card gives the cardholder a credit line they can draw on, repay, and draw on again. Unlike a charge card, the balance does not have to be cleared each cycle — whatever is carried forward accrues interest. That difference is what makes the product a lending business rather than a payments one.
## Overview
### Key Concepts
Three mechanisms define how a revolving credit program behaves. Everything else follows from how you configure them.
Before a card is issued, someone decides whether to extend credit and how much. The outcome is a **credit limit** — the maximum balance the cardholder may carry — which is set on the account and governs how much spending power the card has.
Available credit is the limit minus the current balance, so it falls as the cardholder spends and recovers as they repay.
Underwriting can run on Synctera or on your own platform. See [Who Decides What](#who-decides-what).
The account is billed on a **cycle**, usually monthly. At the end of each cycle Synctera closes the period and produces a statement showing the transactions, the statement balance, the minimum payment due, and the due date.
Interest accrues on balances carried past the due date, at the APR configured for the account. Because interest is calculated from balances the platform holds, **Synctera is the source of truth for interest and fee calculations**.
The cardholder chooses how much to pay: the full statement balance, the minimum due, or something in between. What they choose determines what interest they pay.
A **grace period** is an interval after the statement date during which paying in full avoids interest on purchases. Paying less than the full balance typically forfeits it for that cycle.
### How It Differs from a Charge Card
Synctera supports both. The distinction matters because it changes the account type, the disclosures, and the economics.
| | Revolving credit card | Charge card |
| - | - | - |
| Carrying a balance | Allowed across cycles | Must be paid in full each cycle |
| Interest | Accrues on carried balances | None, since nothing is carried |
| Payment options | Full, minimum, or partial | Full balance only |
| Primary revenue | Interest and fees, plus interchange | Interchange and fees |
| Account type | `CREDIT_CARD` | `CHARGE_SECURED`, `CHARGE_UNSECURED` |
See [Secured Smart Card](/v2/docs/build-smart-card) and [Unsecured Charge Card](/v2/docs/build-charge-card) for the charge products.
### Who Decides What
A revolving program has more moving parts than a debit program, and they are not all on the same side.
| Responsibility | Options |
| - | - |
| **Underwriting** | Synctera's decisioning workflow, or your own engine. With your own, you decide off-platform and report the outcome back. |
| **Capital** | Whoever funds the receivable — you, a debt provider, or your sponsor bank. |
| **Authorization decisions** | Synctera checks account standing, spend controls, AVS, and fraud. If you hold state Synctera does not — an external credit line, for instance — you can join the authorization flow and approve or decline each transaction yourself. |
| **Interest and fee calculation** | Synctera, always. |
| **Collections** | Typically you, or a servicer you appoint. |
## API Flow
Revolving credit cards require additional configurations for your tenant on Synctera. Please work with your Synctera Implementation & Onboarding manager to get set up.
The rest of this guide walks the sequence from a new customer to a live card.
```mermaid mermaid theme={"system"}
%%{init: {"fontFamily": "sans-serif"}}%%
flowchart TB
A["Create and verify the customer"] --> B["Record disclosures"]
B --> C["Create the application"]
C --> D{"Decision"}
D -->|Approved| E["Create the account
with credit_limit"]
D -->|Declined| F["Record an adverse action"]
E --> G["Issue the card"]
G --> H["Add authorized users"]
```
### Step 1 — Create and Verify the Customer
For a consumer program, create the person and run KYC. For a business program, create the business, run KYB, and create each beneficial owner as a person in their own right.
* [Create a Personal Customer](/v2/docs/create-a-personal-customer)
* [Create a Business](/v2/docs/create-a-business)
* [KYC/KYB Verification](/v2/docs/kyc-kyb-verification)
If you run identity verification with your own vendor, report the results to Synctera rather than having Synctera re-run them. See [External Vendor KYC/KYB Verification](/v2/docs/external-vendor-kyc-kyb-verification).
Where the sponsor bank requires it, upload enhanced due diligence against the person or business record. See [Enhanced Due Diligence](/v2/docs/enhanced-due-diligence-guide).
For a business program, link each beneficial owner to the business with [Create Relationship](/v2/reference/createrelationship). A person is a beneficial owner if they hold 25 percent or more of the equity interest; people with significant management responsibility need a relationship too.
### Step 2 — Record Disclosures
Record the customer's acknowledgement of each required disclosure.
See [Record Disclosure Acceptance](/v2/docs/record-disclosure-acceptance).
### Step 3 — Create the Application
A revolving credit account cannot be created without an application. Even when you have already approved the customer on your own platform, this call is what starts the issuing process on Synctera.
```shell Shell theme={"system"}
curl -X POST "$baseurl/v2/applications" \
-H "Authorization: Bearer $apikey" \
-H 'Content-Type: application/json' \
--data-binary '{
"type": "CREDIT_CARD",
"account_template_id": "{ACCOUNT_TEMPLATE_ID}",
"provider": "loanpro",
"applicant": {
"type": "personal",
"personal": {
"person_id": "{PERSON_ID}"
}
}
}'
```
`type`, `account_template_id`, `provider`, and `applicant` are required. `requested_credit_limit` is optional, in cents.
See [Credit Applications](/v2/docs/credit-applications-guide) and [Create Application](/v2/reference/createapplication).
### Step 4 — Record the Credit Decision
**If Synctera runs underwriting**, the decisioning workflow returns the outcome and updates the application.
**If you run your own underwriting**, patch the application with the result:
```shell Shell theme={"system"}
curl -X PATCH "$baseurl/v2/applications/{APPLICATION_ID}" \
-H "Authorization: Bearer $apikey" \
-H 'Content-Type: application/json' \
--data-binary '{
"applicant": {
"type": "personal",
"personal": {
"person_id": "{PERSON_ID}"
}
},
"status": "completed",
"decision": "approved",
"credit_limit": 500000,
"interest_rate": 1250
}'
```
`credit_limit` is in cents and `interest_rate` is in basis points, so the values above are a \$5,000 limit at 12.50% APR. Both may be omitted.
An approved application comes back with a status of `CREDIT_APPROVED`. Once an account is created from it, the status becomes `CREDIT_ACCEPTED_BY_CUSTOMER`.
See [Update Application](/v2/reference/patchapplication).
### Step 5 — Handle a Declined Application
If the application is declined, the applicant must receive an adverse action notice. Under Regulation B and the FCRA this has to reach them within 30 days of the decision and must state the specific reasons for denial, along with the required ECOA and enforcement agency language.
Create the record with [Create Adverse Action](/v2/reference/createadverseaction), then mark the application `CREDIT_DENIED` with the adverse action ID attached. This is required for personal customers and optional for business customers.
See [Adverse Actions](/v2/docs/adverse-actions-guide).
### Step 6 — Create the Account
Create the account from the template configured for your revolving product, referencing the approved application.
```shell Shell theme={"system"}
curl -X POST "$baseurl/v2/accounts" \
-H "Authorization: Bearer $apikey" \
-H 'Content-Type: application/json' \
--data-binary '{
"account_type": "CREDIT_CARD",
"account_template_id": "{ACCOUNT_TEMPLATE_ID}",
"application_id": "{APPLICATION_ID}",
"customer_id": "{CUSTOMER_ID}"
}'
```
**The credit limit is not set here.** It comes from the approved application — the `credit_limit` recorded in [Step 4](#step-4--record-the-credit-decision) — and the account inherits it through `application_id`. There is no `credit_limit` field on a `CREDIT_CARD` account.
You can attach `fee_product_ids`, `reward_product_ids`, and `spend_control_ids` here, or inherit them from the template. See [Create Accounts](/v2/docs/create-accounts-guide), [Fees and Rewards](/v2/docs/fees-and-rewards), and [Spend Controls](/v2/docs/spend-controls-guide).
### Step 7 — Issue the Card
Issue against the revolving account with `"type": "CREDIT"`, using a card product on a BIN with unsecured credit enabled.
```shell Shell theme={"system"}
curl -X POST "$baseurl/v2/cards" \
-H "Authorization: Bearer $apikey" \
-H 'Content-Type: application/json' \
--data-binary '{
"type": "CREDIT",
"card_details": {
"form": "VIRTUAL",
"account_id": "{ACCOUNT_ID}",
"customer_id": "{CUSTOMER_ID}",
"card_product_id": "{CARD_PRODUCT_ID}"
}
}'
```
Issue the virtual card first so the customer can spend immediately, then the physical card if your program offers one. Physical cards require activation; virtual cards do not. See [Issue a Card](/v2/docs/issue-a-card).
Both forms can be added to Apple Pay and Google Wallet. See [Digital Wallets and Tokenization](/v2/docs/digital-wallets).
### Step 8 — Add Authorized Users
Business programs often issue additional cards to employees. Each authorized user's card is issued against the same revolving account, so all spend draws on one credit line.
Create the authorized user as a person and verify them. See [Create a Personal Customer](/v2/docs/create-a-personal-customer).
Give them a relationship to the revolving account with [Create Account Relationship](/v2/reference/createaccountrelationship).
Issue against the same `account_id`, with the authorized user as `customer_id`.
To control spend per authorized user rather than across the whole account, see the funding hierarchy options in [Card-Account Relationship and Funding Hierarchies](/v2/docs/card-accounts-funding).
## Running the Program
### Authorization
Synctera evaluates each authorization against account standing, spend controls, address verification, and fraud rules. A transaction that would take the balance past the credit limit is declined.
If you hold state that Synctera does not — an external credit line, your own exposure rules — you can join the authorization flow and return an approve or decline decision per transaction. The network imposes a hard response deadline, and a late response means the transaction is declined automatically.
See [FinTech in the Auth Flow](/v2/docs/card-transactions#fintech-in-the-auth-flow).
### Statements
At the end of each billing cycle Synctera closes the period and generates a statement, including a PDF. Subscribe to the statement webhook to know when one is ready, then retrieve it with [List Statements](/v2/reference/liststatements) and [Get Statement PDF](/v2/reference/getstatementpdf).
Regulation requires that statements be available to the customer in your application and as a downloadable PDF, and that customers can request paper statements.
See [Statements](/v2/docs/statements-guide).
### Payments
Record payments against the account with [Make Payment](/v2/reference/makepayment). Synctera applies the payment and recalculates the balance, the available credit, and any interest.
Where you own the repayment experience and collect funds outside Synctera, you still report the portion allocated to card spend so the platform's balances stay correct.
### Interest and Fees
Synctera calculates and posts interest and fees to the account. Common triggers:
* No payment by the due date — a late fee may be assessed and interest accrues on the full statement balance
* A payment below the minimum due — a late fee may be assessed and interest accrues on the unpaid balance
* A payment above the minimum but below the statement balance — interest accrues on the unpaid portion
Cross-border and FX fees are separate from credit fees and are triggered by where the card is used. They are configured on the card product and in your fee rules. See [Fees and Rewards](/v2/docs/fees-and-rewards).
The complete set of rules and fees for your program is defined in the card agreement.
### Rewards
Rewards are applied automatically when their conditions are met — a cleared transaction, for example — and posted to the account as a statement credit. See [Fees and Rewards](/v2/docs/fees-and-rewards).
### Disputes
Cardholders can dispute any card transaction. Raising a dispute opens a case in the Synctera Console and starts the investigation. See [Card Transaction Disputes](/v2/docs/card-transaction-disputes).
### Delinquency and Collections
Your program configuration sets how long past the due date a card is suspended, when the customer is reported delinquent, and when the balance is charged off. Collections are typically your responsibility or a servicer's.
### Credit Bureau Reporting
Because balances and payment history live on the account, a revolving program can furnish to the credit bureaus. Furnishing requires bureau credentialing for your program, arranged with your Synctera representative.