The Payments workspace related to this reference article.
Payments connects Brisk sales and customer receivables to card-present terminals, online payment links, stored payment methods, and scheduled collection. The processor is the authority for approval and settlement; Brisk preserves the customer, business document, request, status, and accounting handoff needed to operate and investigate the payment.
Choose the payment workflow
- Configure EMV terminals before taking card-present payments and assign the intended terminal to the user or workstation.
- Create an email payment request when a customer needs a signed online link for a sale or specified amount. Check its remote status before recreating or deleting a pending request.
- Store a customer payment method only through the tokenized setup flow with the customer’s authorization; Brisk should not store raw card or bank credentials.
- Use receivable payment plans and payment subscriptions for authorized recurring collection, with deliberate amount, cadence, next-run date, payment method, and fallback behavior.
- Review the related sale, customer, and receivable transactions after approval to confirm the business balance changed as expected.
When payment status is uncertain
Do not submit the same payment repeatedly because the browser appears stalled. First check the processor status or gateway attempt, then look for the resulting Brisk tender or receivable transaction. Preserve the original request and transaction identifiers when escalating. Cancel or recreate a request only after determining that it was not approved and will not settle later.
Payment controls
Confirm customer, source sale or invoice, amount, allowed tender, terminal, and authorization before submission. Limit payment configuration and stored-method access to authorized staff. Never copy full card numbers, bank details, processor secrets, or payment tokens into notes or documentation. Reconcile processor settlements to Brisk tenders and bank deposits; a successful authorization is not by itself proof of deposit.
# Core Records
# Customer Payment Methods
# Customer Payment Methods
Purpose and when to use this record
Maintain a customer-authorized tokenized card or ACH method without storing raw payment credentials in Brisk.
## At a glance
- **Identify it by:** **Nickname**, and **Status**.
- **Check its business context:** **Customer**.
- **Why care:** Customer, source document, amount, authorization, processor status, and settlement are separate controls. Verify all of them before retrying or treating a payment as complete.
- **Why care:** Availability and publication flags affect future use without erasing history. Prefer disabling an obsolete setup record when existing transactions still refer to it.
- **Why care:** Status communicates workflow progress to other staff. Change it only when the underlying work, approval, payment, or handoff has actually occurred.
## Before you begin
You need the Brisk permission for the action you are taking on customer payment methods. If a Create, Edit, or Delete control is absent, do not work around it with another user’s account; ask an administrator to review your role.
Open the correct customer first and confirm that NMI recurring/tokenized payments are enabled. The setup flow is customer-specific and requires permission to add customer payment methods.
Create a Customer Payment Method
Customer payment methods are not created by typing a vault ID into an ordinary Brisk form. Choose **Add Payment Method** from the customer or subscription workflow. Brisk creates a signed, customer-specific setup link and sends the browser to the secure payment-method screen. If recurring payments are disabled, Brisk returns to the customer instead of opening setup.
1. Verify the customer name and the recurring agreement before opening setup.
2. Complete the provider-hosted card or ACH authorization. Never paste a full card number, bank account number, or processor token into Brisk notes.
3. Return to the customer and open **Customer Payment Methods**. Confirm the method type, status, and authorization time.
4. Give the method a recognizable **Nickname** and deliberately choose **Default For Customer**. Setting a new default automatically clears the former default.
The gateway vault ID and initial transaction ID are processor references created by the secure flow; staff should not invent or hand-edit them.
Delete a Customer Payment Method
Delete this Customer Payment Method only if it is an unused duplicate or setup mistake. Once other records refer to it, preserve that history and make the value inactive when the screen provides that option.
If the record is merely obsolete, use **Active** to remove it from future use while preserving existing references.
Before confirming, check for related **Customer Receivable Payment Plans**, **Payment Gateway Attempts**, and **Subscriptions**. Brisk may refuse deletion when another record depends on this one; resolve the duplicate or use the supported correction workflow instead of breaking the trail.
On the confirmation page, verify **Nickname**, and **Status**. After confirmation, return to the Customer Payment Methods list and make sure only the intended Customer Payment Method was removed.
Review Customer Payment Method details
The Customer Payment Methods detail screen in the Brisk documentation demo.
Use the detail page as the shared record of what this Customer Payment Method currently means. Verify **Payment Provider**, **Payment Method**, **Active**, and **Status** before relying on it for a decision.
Follow **Customer** to determine whether the issue is on this Customer Payment Method or on one of those linked records.
Next check: Use the tokenized method only for the authorized customer and purpose, then verify its default/active state without exposing processor credentials.
Edit an existing Customer Payment Method
The Customer Payment Methods update screen in the Brisk documentation demo.
The edit screen intentionally limits staff to **Nickname**, **Active**, **Default For Customer**, and **Status**. Use it to rename a method, stop future charges, or change the customer's preferred method. It does not change the card, bank account, customer, or provider token.
Deactivate a revoked, expired, or no-longer-authorized method before selecting a replacement. If the underlying payment credential changed, run the secure setup flow again and then make the new method the default. After saving, verify that scheduled receivable plans point to the intended active method.
Find and review customer payment methods
The Customer Payment Methods list screen in the Brisk documentation demo.
Use the Customer Payment Methods list to find the correct record before opening or changing it. Compare **Nickname**, and **Status**. Confirm its context with **Customer**.
Open the Customer Payment Method whose **Nickname**, and **Status** match the task. If it is missing, clear the list filters and recheck **Payment Provider**, **Payment Method**, **Active**, and **Status** rather than creating a replacement immediately.
## Fields and business rules
Brisk stores 13 user-relevant fields for this Customer Payment Method, including 1 linked-record selection and 2 controlled-choice fields. Create and edit screens may hide calculated or workflow-managed values from this full reference.
| Field | Required | What it controls |
|---|---:|---|
| **Customer** | Yes | Links this Customer Payment Method to the selected Customer; verify the relationship before saving. |
| **Payment Provider** | No | The payment provider recorded for this customer payment method. Available values: NMI, eBizCharge. |
| **Payment Method** | No | The payment method recorded for this customer payment method. Available values: Credit/Debit Card, eCheck/ACH. |
| **Nickname** | No | The nickname recorded for this customer payment method. |
| **Gateway Customer Vault Id** | Yes | Tokenized customer-vault reference at the payment provider. |
| **Initial Transaction Id** | No | Initial storage/validation transaction used for stored credential follow-up charges. |
| **Active** | No | Whether this customer payment method is active and available for use. |
| **Default For Customer** | No | Whether the default for customer option applies to this customer payment method. |
| **Status** | No | Current status of this customer payment method. |
| **Raw Response** | No | Structured raw response data stored for this customer payment method. |
| **Authorization Accepted At** | No | Date and time recorded for authorization accepted at on this customer payment method. |
| **Authorization Ip** | No | The authorization ip recorded for this customer payment method. |
| **Authorization User Agent** | No | The authorization user agent recorded for this customer payment method. |
## What happens next
Use the tokenized method only for the authorized customer and purpose, then verify its default/active state without exposing processor credentials.
## Common mistakes and troubleshooting
- **The record will not save:** Recheck **Customer**, and **Gateway Customer Vault Id** and any message beside the field. A required related record may also be inactive or unavailable to your role.
- **The record saved but is not available where expected:** Recheck **Payment Provider**, **Payment Method**, **Active**, and **Status**, then clear the filters on the destination list. Those controls determine payment authorization, collection timing, customer balances, and settlement review even when the other fields saved successfully.
- **The values look right but the result is wrong:** Open **Customer** from the detail page. Correct the specific relationship that is wrong instead of forcing a total or status to compensate for it.
# Customer Receivable Payment Plans
# Customer Receivable Payment Plans
Purpose and when to use this record
Schedule authorized collections against a customer’s receivable balance and track each run without duplicating payments.
## At a glance
- **Identify it by:** **Start Date**, **Next Run Date**, and **End Date**.
- **Check its business context:** **Customer**, and **Payment Method**.
- **Why care:** Customer, source document, amount, authorization, processor status, and settlement are separate controls. Verify all of them before retrying or treating a payment as complete.
- **Why care:** Availability and publication flags affect future use without erasing history. Prefer disabling an obsolete setup record when existing transactions still refer to it.
## Before you begin
You need the Brisk permission for the action you are taking on customer receivable payment plans. If a Create, Edit, or Delete control is absent, do not work around it with another user’s account; ask an administrator to review your role.
Confirm recurring/tokenized NMI payments are enabled, the customer has an open receivable balance, and the customer has authorized an active stored payment method. A stored method cannot be used for a different customer.
Create a Customer Receivable Payment Plan
The Customer Receivable Payment Plans create screen in the Brisk documentation demo.
1. Select the **Customer**, then choose one of that customer's active stored **Payment Methods**.
2. Enter the authorized **Monthly Payment Amount** and **Day of Month**.
3. Set **Start Date** and **Next Run Date** deliberately. The scheduled process considers active plans whose next run is blank or due; a future date is not charged early.
4. Use **End Date** or **Maximum Payments** when the authorization has a fixed term. Zero maximum payments means open-ended, so do not use it accidentally.
5. Save, then review the detail page before making the plan active.
On each due run, Brisk charges the smaller of the scheduled amount and the customer's current account balance. It stops a plan whose balance is zero, term has ended, or maximum count was reached.
Delete a Customer Receivable Payment Plan
Delete this Customer Receivable Payment Plan only when it was entered by mistake and no downstream history depends on it. Preserve the gateway request and result; void, refund, cancel, or replace it through the supported processor-aware workflow.
If the record is merely obsolete, use **Active** to remove it from future use while preserving existing references.
On the confirmation page, verify **Start Date**, **Next Run Date**, and **End Date**. After confirmation, return to the Customer Receivable Payment Plans list and make sure only the intended Customer Receivable Payment Plan was removed.
Review Customer Receivable Payment Plan details
The Customer Receivable Payment Plans detail screen in the Brisk documentation demo.
Use the detail page to compare **Monthly Payment Amount**, **Next Run Date**, **Payments Processed**, **Total Processed**, **Last Run At**, and **Last Result**. The **Run Now** action can contact the processor and must be treated as a real charge, not a preview. Brisk uses a plan-and-date idempotency key to resist duplicate processing, but staff should still investigate the existing attempt before retrying.
Follow **Customer**, and **Payment Method** to determine whether the issue is on this Customer Receivable Payment Plan or on one of those linked records.
Next check: Review each scheduled collection result against the customer’s open receivables and stop the plan when its authorized balance or term is complete.
Run a due plan now
Open the plan detail and choose **Run Now** only when the plan is due and you intend to contact the processor. The confirmation is not a preview. Before submitting, verify the active stored method belongs to the customer, the open balance is positive, and the last result does not already show a successful or pending attempt for today. Afterward, recheck **Last Run At**, **Last Result**, **Payments Processed**, **Total Processed**, the gateway attempt, and the resulting customer credit or pending-settlement state.
Edit an existing Customer Receivable Payment Plan
Edit the schedule only when the customer's authorization supports the new amount, method, or term. Do not rewrite **Payments Processed**, **Total Processed**, **Last Run At**, or **Last Result** to make a failed run look successful; those values explain what automation actually did.
For a failed card charge, correct the stored method or authorization and review the gateway attempt before retrying. ACH may remain pending until settlement according to policy; do not create a manual customer credit merely because the submission was accepted. Deactivate the plan immediately when authorization is withdrawn.
Find and review customer receivable payment plans
The Customer Receivable Payment Plans list screen in the Brisk documentation demo.
Use the Customer Receivable Payment Plans list to find the correct record before opening or changing it. Compare **Start Date**, **Next Run Date**, and **End Date**. Confirm its context with **Customer**, and **Payment Method**.
Open the Customer Receivable Payment Plan whose **Start Date**, **Next Run Date**, and **End Date** match the task. If it is missing, clear the list filters and recheck **Payments Processed**, **Total Processed**, and **Active** rather than creating a replacement immediately.
## Fields and business rules
Brisk stores 14 user-relevant fields for this Customer Receivable Payment Plan, including 2 linked-record selections and 0 controlled-choice fields. Create and edit screens may hide calculated or workflow-managed values from this full reference.
| Field | Required | What it controls |
|---|---:|---|
| **Customer** | Yes | Links this Customer Receivable Payment Plan to the selected Customer; verify the relationship before saving. |
| **Payment Method** | No | Links this Customer Receivable Payment Plan to the selected Customer Payment Method; verify the relationship before saving. |
| **Monthly Payment Amount** | No | The monthly payment amount value recorded for this customer receivable payment plan. |
| **Day Of Month** | No | The day of month value recorded for this customer receivable payment plan. |
| **Start Date** | No | Date recorded for start date on this customer receivable payment plan. |
| **Next Run Date** | No | Date recorded for next run date on this customer receivable payment plan. |
| **End Date** | No | Date recorded for end date on this customer receivable payment plan. |
| **Maximum Payments** | No | Use 0 for open ended. |
| **Payments Processed** | No | The payments processed value recorded for this customer receivable payment plan. |
| **Total Processed** | No | The total processed value recorded for this customer receivable payment plan. |
| **Active** | No | Whether this customer receivable payment plan is active and available for use. |
| **Completed At** | No | Date and time recorded for completed at on this customer receivable payment plan. |
| **Last Run At** | No | Date and time recorded for last run at on this customer receivable payment plan. |
| **Last Result** | No | The last result recorded for this customer receivable payment plan. |
## What happens next
Review each scheduled collection result against the customer’s open receivables and stop the plan when its authorized balance or term is complete.
## Common mistakes and troubleshooting
- **The record will not save:** Recheck **Customer** and any message beside the field. A required related record may also be inactive or unavailable to your role.
- **The record saved but is not available where expected:** Recheck **Payments Processed**, **Total Processed**, and **Active**, then clear the filters on the destination list. Those controls determine payment authorization, collection timing, customer balances, and settlement review even when the other fields saved successfully.
- **The values look right but the result is wrong:** Open **Customer**, and **Payment Method** from the detail page. Correct the specific relationship that is wrong instead of forcing a total or status to compensate for it.
# Email Payments
# Email Payments
Purpose and when to use this record
Create and monitor a signed online payment request for a customer or sale, including allowed tenders, amount, and remote status.
## At a glance
- **Identify it by:** **Status**.
- **Check its business context:** **Customer**, and **Customer Credit**.
- **Why care:** Customer, source document, amount, authorization, processor status, and settlement are separate controls. Verify all of them before retrying or treating a payment as complete.
- **Why care:** Status communicates workflow progress to other staff. Change it only when the underlying work, approval, payment, or handoff has actually occurred.
## Before you begin
You need the Brisk permission for the action you are taking on email payments. If a Create, Edit, or Delete control is absent, do not work around it with another user’s account; ask an administrator to review your role.
Confirm the customer record has the correct email address, decide the exact amount and reason for collection, and verify which provider and tender types the business accepts. Saving a new request contacts the configured provider to generate the payment URL.
Create an Email Payment
The Email Payments create screen in the Brisk documentation demo.
1. Select **Customer** and verify the recipient's email on the customer record.
2. Enter **Amount** and a short **Memo** the customer will recognize. Do not put confidential account or card data in the memo.
3. Choose the configured **Payment Provider** and allow card, ACH, or both according to company policy and provider support.
4. Leave **Payment URL**, **Reference Number**, **Status**, and **Customer Credit** to the workflow. Those values document what the provider generated and what Brisk recorded after payment.
5. Save once. Confirm that a payment URL and generated status appear before sending the link.
If the save stalls or the URL is missing, check provider configuration and status before saving or creating another request. A repeated submission can create multiple live collection opportunities.
Delete an Email Payment
Delete this Email Payment only when it was entered by mistake and no downstream history depends on it. Preserve the gateway request and result; void, refund, cancel, or replace it through the supported processor-aware workflow.
On the confirmation page, verify **Status**. After confirmation, return to the Email Payments list and make sure only the intended Email Payment was removed.
Review Email Payment details
The Email Payments detail screen in the Brisk documentation demo.
Use the detail page as the shared record of what this Email Payment currently means. Verify **Payment Provider**, **Amount**, and **Status** before relying on it for a decision.
Follow **Customer**, and **Customer Credit** to determine whether the issue is on this Email Payment or on one of those linked records.
Next check: Send the signed payment link through the approved channel, then check processor status before recreating, canceling, or treating the request as paid.
Edit an existing Email Payment
Do not change customer, amount, or allowed tender after sending the link; the recipient may still be viewing the provider's original request. If the business request changed, first establish whether the existing link can still settle, then cancel or retire it through the supported provider workflow and issue a replacement.
Treat **Reference Number**, **Status**, and **Customer Credit** as workflow results. A completed customer credit is the Brisk accounting evidence; an authorization or browser confirmation alone is not. Preserve the original record when troubleshooting so support can match the Brisk ID, payment URL, provider reference, and customer credit.
Find and review email payments
The Email Payments list screen in the Brisk documentation demo.
Use the Email Payments list to find the correct record before opening or changing it. Compare **Status**. Confirm its context with **Customer**, and **Customer Credit**.
Open the Email Payment whose **Status** matches the task. If it is missing, clear the list filters and recheck **Payment Provider**, and **Status** rather than creating a replacement immediately.
## Fields and business rules
Brisk stores 9 user-relevant fields for this Email Payment, including 2 linked-record selections and 1 controlled-choice field. Create and edit screens may hide calculated or workflow-managed values from this full reference.
| Field | Required | What it controls |
|---|---:|---|
| **Customer** | Yes | Records the customer that the transaction was emailed to. |
| **Payment Provider** | No | Payment provider used for this payment request. Available values: NMI, eBizCharge. |
| **Amount** | No | The dollar amount to request from the customer. |
| **Reference Number** | No | Records the reference number for a successful payment, used when voiding a transaction. |
| **Status** | No | Notes the current status of this email pay link. |
| **Memo** | No | If provided, this short description will be shown to the customer on the payment form. |
| **Customer Credit** | No | Records the customer credit used to apply a successful payment in the system. |
| **Allow Credit/Debit Card** | No | Allow card payment on this request. |
| **Allow Echeck/Ach** | No | Allow eCheck/ACH payment on this request when supported by the provider. |
## What happens next
Send the signed payment link through the approved channel, then check processor status before recreating, canceling, or treating the request as paid.
## Common mistakes and troubleshooting
- **The record will not save:** Recheck **Customer** and any message beside the field. A required related record may also be inactive or unavailable to your role.
- **The record saved but is not available where expected:** Recheck **Payment Provider**, and **Status**, then clear the filters on the destination list. Those controls determine payment authorization, collection timing, customer balances, and settlement review even when the other fields saved successfully.
- **The values look right but the result is wrong:** Open **Customer**, and **Customer Credit** from the detail page. Correct the specific relationship that is wrong instead of forcing a total or status to compensate for it.
# EMV Terminals
# Emv Terminals
Purpose and when to use this record
Configure the processor terminal identity used for card-present payments and assign it to the correct user or workstation.
## At a glance
- **Identify it by:** **Name**, and **Pairing Code**.
- **Why care:** Customer, source document, amount, authorization, processor status, and settlement are separate controls. Verify all of them before retrying or treating a payment as complete.
## Before you begin
You need the Brisk permission for the action you are taking on emv terminals. If a Create, Edit, or Delete control is absent, do not work around it with another user’s account; ask an administrator to review your role.
Create an EMV Terminal
The EMV Terminals create screen in the Brisk documentation demo.
Creating a terminal is an external action: the first save asks the configured provider to register the hardware. Have the physical device, serial number, processor account, and pairing information ready before you begin.
1. Use a **Name** that identifies the business location and register, such as “Front Counter 1,” not only the hardware model.
2. Record the serial number and, where used, MAC address so staff can match Brisk to the device in hand.
3. Select the correct **Payment Provider** and enter only the gateway hardware ID or pairing code supplied for this device.
4. Enable EMV, NFC, tip adjustment, and PIN debit only when both the hardware and business workflow support them.
5. Save once and verify the provider registration before assigning the terminal to a user or workstation.
If registration times out, check the processor portal before recreating the record; the first request may have registered successfully.
Delete an EMV Terminal
Delete this EMV Terminal only if it is an unused duplicate or setup mistake. Once other records refer to it, preserve that history and make the value inactive when the screen provides that option.
On the confirmation page, verify **Name**, and **Pairing Code**. After confirmation, return to the EMV Terminals list and make sure only the intended EMV Terminal was removed.
Review EMV Terminal details
The EMV Terminals detail screen in the Brisk documentation demo.
Use the detail page as the shared record of what this EMV Terminal currently means. Verify **Payment Provider** before relying on it for a decision.
Compare the EMV Terminal with its source document or approved setup request before deciding that it needs correction.
Next check: Assign the terminal to the intended user or workstation, run a controlled test transaction, and reconcile its processor identity before live use.
Edit an existing EMV Terminal
Saving an existing terminal sends its EMV, NFC, tip-adjust, and PIN-debit configuration to the registered gateway device. Compare the Brisk gateway ID and physical serial number first; do not repurpose a historical terminal record for different hardware. After changing capabilities, run a controlled low-risk test and confirm both the Brisk result and processor transaction before taking customer payments.
Find and review emv terminals
The EMV Terminals list screen in the Brisk documentation demo.
Use the Emv Terminals list to find the correct record before opening or changing it. Compare **Name**, and **Pairing Code**. Compare the full identifier rather than relying on a similar name.
Open the EMV Terminal whose **Name**, and **Pairing Code** match the task. If it is missing, clear the list filters and recheck **Payment Provider** rather than creating a replacement immediately.
## Fields and business rules
Brisk stores 11 user-relevant fields for this EMV Terminal, including 0 linked-record selections and 1 controlled-choice field. Create and edit screens may hide calculated or workflow-managed values from this full reference.
| Field | Required | What it controls |
|---|---:|---|
| **Name** | Yes | Friendly name to help identify the terminal, e.g. "Register 1". |
| **Description** | No | Additional information about the terminal, possibly include the brand, model, location, etc. |
| **Mac Address** | No | Optionally identify the MAC address of the terminal. |
| **Serial Number** | No | Optionally identify the serial number of the terminal. |
| **Payment Provider** | No | Payment provider that owns this terminal registration. Available values: NMI, eBizCharge. |
| **Payment Gateway Id** | No | Stores the unique hardware ID from the payment gateway. |
| **Pairing Code** | No | Stores the pairing code from the payment gateway used to activate the device. |
| **Enable Emv** | No | Enable or disable chip reader (EMV) features on this device, if supported. |
| **Enable Nfc** | No | Enable or disable tap-to-pay features on this device, if supported. |
| **Enable Tip Adjust** | No | Enable or disable tip adjustment features on this device, if supported. |
| **Enable Pin Debit** | No | Enable or disable PIN debit card transactions on this device, if supported. |
## What happens next
Assign the terminal to the intended user or workstation, run a controlled test transaction, and reconcile its processor identity before live use.
## Common mistakes and troubleshooting
- **The record will not save:** Recheck **Name** and any message beside the field. A required related record may also be inactive or unavailable to your role.
- **The values look right but the result is wrong:** Compare this EMV Terminal with the source document or approved setup decision, then check the downstream screen where it is used.
# Payment Plans
# Payment Plans
Purpose and when to use this record
Review legacy or provider-managed amount, cadence, duration, and processor identifiers. These records are reference-only in Brisk-managed billing mode; use Customer Receivable Payment Plans for supported scheduled collection.
## At a glance
- **Identify it by:** **Name**, and **Start Date**.
- **Why care:** Customer, source document, amount, authorization, processor status, and settlement are separate controls. Verify all of them before retrying or treating a payment as complete.
- **Why care:** Availability and publication flags affect future use without erasing history. Prefer disabling an obsolete setup record when existing transactions still refer to it.
## Before you begin
You need the Brisk permission for the action you are taking on payment plans. If a Create, Edit, or Delete control is absent, do not work around it with another user’s account; ask an administrator to review your role.
Why Create is unavailable
The Create route deliberately returns to the Payment Plans list with a message that gateway-managed plans are not Brisk's primary billing path. Brisk also does not create autonomous gateway plans from ordinary model saves. To schedule collection against a customer's receivable balance, create a **Customer Receivable Payment Plan** with an authorized stored method, amount, and next-run date.
Delete a Payment Plan
Delete this Payment Plan only when it was entered by mistake and no downstream history depends on it. Preserve the gateway request and result; void, refund, cancel, or replace it through the supported processor-aware workflow.
If the record is merely obsolete, use **Active** to remove it from future use while preserving existing references.
Before confirming, check for related **Payment Subscriptions**. Brisk may refuse deletion when another record depends on this one; resolve the duplicate or use the supported correction workflow instead of breaking the trail.
On the confirmation page, verify **Name**, and **Start Date**. After confirmation, return to the Payment Plans list and make sure only the intended Payment Plan was removed.
Review Payment Plan details
The Payment Plans detail screen in the Brisk documentation demo.
Use the detail page as the shared record of what this Payment Plan currently means. Verify **Payment Provider**, **Amount**, **Start Date**, and **Active** before relying on it for a decision.
Compare the Payment Plan with its source document or approved setup request before deciding that it needs correction.
Next check: Apply the plan only to customers whose authorization and collection terms match it, and review generated activity for failures or duplicate schedules.
Why editing is unavailable
The Edit route also returns to the list because these provider-managed records are read-only in Brisk-managed billing mode. Do not try to change cadence or amount by editing the database or processor ID. Determine whether the authoritative schedule is in the processor, a Sales Subscription, or a Customer Receivable Payment Plan, then use that workflow's supported change or cancellation process.
Find and review payment plans
The Payment Plans list screen in the Brisk documentation demo.
Use the Payment Plans list to find the correct record before opening or changing it. Compare **Name**, and **Start Date**. Compare the full identifier rather than relying on a similar name.
Open the Payment Plan whose **Name**, and **Start Date** match the task. If it is missing, clear the list filters and recheck **Payment Provider**, and **Active** rather than creating a replacement immediately.
## Fields and business rules
Brisk stores 10 user-relevant fields for this Payment Plan, including 0 linked-record selections and 1 controlled-choice field. Create and edit screens may hide calculated or workflow-managed values from this full reference.
| Field | Required | What it controls |
|---|---:|---|
| **Payment Provider** | No | The payment provider recorded for this payment plan. Available values: NMI, eBizCharge. |
| **Name** | Yes | Human-readable name for this payment plan. |
| **Gateway Plan Id** | No | Provider plan identifier. |
| **Amount** | No | The amount value recorded for this payment plan. |
| **Number Of Payments** | No | Use 0 for until canceled. |
| **Month Frequency** | No | The month frequency value recorded for this payment plan. |
| **Day Of Month** | No | The day of month value recorded for this payment plan. |
| **Start Date** | No | Date recorded for start date on this payment plan. |
| **Active** | No | Whether this payment plan is active and available for use. |
| **Raw Response** | No | Structured raw response data stored for this payment plan. |
## What happens next
Use this page to identify a legacy/provider plan. Operate new receivable schedules through Customer Receivable Payment Plans and new sales billing through Sales Subscriptions.
## Common mistakes and troubleshooting
- **The record will not save:** Recheck **Name** and any message beside the field. A required related record may also be inactive or unavailable to your role.
- **The record saved but is not available where expected:** Recheck **Payment Provider**, and **Active**, then clear the filters on the destination list. Those controls determine payment authorization, collection timing, customer balances, and settlement review even when the other fields saved successfully.
- **The values look right but the result is wrong:** Compare this Payment Plan with the source document or approved setup decision, then check the downstream screen where it is used.
# Payment Subscriptions
# Payment Subscriptions
Purpose and when to use this record
Review a provider-managed recurring subscription's customer, plan, amount, cadence, status, vault reference, and gateway identifier. These records are read-only in Brisk-managed billing mode.
## At a glance
- **Identify it by:** **Status**, and **Start Date**.
- **Check its business context:** **Customer**, and **Payment Plan**.
- **Why care:** Customer, source document, amount, authorization, processor status, and settlement are separate controls. Verify all of them before retrying or treating a payment as complete.
- **Why care:** Status communicates workflow progress to other staff. Change it only when the underlying work, approval, payment, or handoff has actually occurred.
## Before you begin
You need the Brisk permission for the action you are taking on payment subscriptions. If a Create, Edit, or Delete control is absent, do not work around it with another user’s account; ask an administrator to review your role.
Have valid **Customer** records ready first. Those selections determine where this Payment Subscription belongs and which later screens can find it.
Why Create is unavailable
The Create route deliberately returns to the list. Brisk does not create autonomous gateway subscriptions from this generic record. For repeating sales, use the Sales Subscription workflow and add the customer's payment method through its secure setup link. For collection against an existing account balance, use a Customer Receivable Payment Plan.
Delete a Payment Subscription
Delete this Payment Subscription only when it was entered by mistake and no downstream history depends on it. Preserve the gateway request and result; void, refund, cancel, or replace it through the supported processor-aware workflow.
On the confirmation page, verify **Status**, and **Start Date**. After confirmation, return to the Payment Subscriptions list and make sure only the intended Payment Subscription was removed.
Review Payment Subscription details
The Payment Subscriptions detail screen in the Brisk documentation demo.
Use the detail page as the shared record of what this Payment Subscription currently means. Verify **Payment Provider**, **Payment Method**, **Status**, **Amount**, and **Start Date** before relying on it for a decision.
Follow **Customer**, and **Payment Plan** to determine whether the issue is on this Payment Subscription or on one of those linked records.
Next check: Monitor the next-run date and every generated payment; resolve processor failures without creating a second active subscription for the same obligation.
Why editing is unavailable
The Edit route returns to the list because the record is a provider-managed reference. Never change **Gateway Subscription ID**, **Customer Vault ID**, status, or cadence directly to force Brisk to match an assumption. Compare the record with the processor and the related Brisk Sales Subscription, then cancel, replace, or correct it through the authoritative workflow. Before creating any replacement, verify that the former subscription cannot still collect.
Find and review payment subscriptions
The Payment Subscriptions list screen in the Brisk documentation demo.
Use the Payment Subscriptions list to find the correct record before opening or changing it. Compare **Status**, and **Start Date**. Confirm its context with **Customer**, and **Payment Plan**.
Open the Payment Subscription whose **Status**, and **Start Date** match the task. If it is missing, clear the list filters and recheck **Payment Provider**, **Payment Method**, and **Status** rather than creating a replacement immediately.
## Fields and business rules
Brisk stores 13 user-relevant fields for this Payment Subscription, including 2 linked-record selections and 2 controlled-choice fields. Create and edit screens may hide calculated or workflow-managed values from this full reference.
| Field | Required | What it controls |
|---|---:|---|
| **Payment Provider** | No | The payment provider recorded for this payment subscription. Available values: NMI, eBizCharge. |
| **Customer** | Yes | Links this Payment Subscription to the selected Customer; verify the relationship before saving. |
| **Payment Plan** | No | Links this Payment Subscription to the selected Payment Plan; verify the relationship before saving. |
| **Gateway Subscription Id** | No | The gateway subscription id recorded for this payment subscription. |
| **Payment Method** | No | The payment method recorded for this payment subscription. Available values: Credit/Debit Card, eCheck/ACH. |
| **Status** | No | Current status of this payment subscription. |
| **Amount** | No | The amount value recorded for this payment subscription. |
| **Month Frequency** | No | The month frequency value recorded for this payment subscription. |
| **Day Of Month** | No | The day of month value recorded for this payment subscription. |
| **Number Of Payments** | No | The number of payments value recorded for this payment subscription. |
| **Start Date** | No | Date recorded for start date on this payment subscription. |
| **Customer Vault Id** | No | The customer vault id recorded for this payment subscription. |
| **Raw Response** | No | Structured raw response data stored for this payment subscription. |
## What happens next
Use the gateway ID and customer context to reconcile legacy provider activity. Operate current recurring billing through Sales Subscriptions or Customer Receivable Payment Plans, as appropriate.
## Common mistakes and troubleshooting
- **The record will not save:** Recheck **Customer** and any message beside the field. A required related record may also be inactive or unavailable to your role.
- **The record saved but is not available where expected:** Recheck **Payment Provider**, **Payment Method**, and **Status**, then clear the filters on the destination list. Those controls determine payment authorization, collection timing, customer balances, and settlement review even when the other fields saved successfully.
- **The values look right but the result is wrong:** Open **Customer**, and **Payment Plan** from the detail page. Correct the specific relationship that is wrong instead of forcing a total or status to compensate for it.
