Core Records

Customer Payment Methods
Customer Receivable Payment Plans
Email Payments
EMV Terminals
Payment Plans
Payment Subscriptions

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.

Verify the customer name and the recurring agreement before opening setup.
Complete the provider-hosted card or ACH authorization. Never paste a full card number, bank account number, or processor token into Brisk notes.
Return to the customer and open Customer Payment Methods. Confirm the method type, status, and authorization time.
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

Brisk Customer Payment Methods detail screen displayed with fictional documentation-demo data. — 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

Brisk Customer Payment Methods update screen displayed with fictional documentation-demo data. — 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

Brisk Customer Payment Methods list screen displayed with fictional documentation-demo data. — 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

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

Brisk Customer Receivable Payment Plans create screen displayed with fictional documentation-demo data. — The Customer Receivable Payment Plans create screen in the Brisk documentation demo.

Select the Customer, then choose one of that customer's active stored Payment Methods.
Enter the authorized Monthly Payment Amount and Day of Month.
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.
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.
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

Brisk Customer Receivable Payment Plans detail screen displayed with fictional documentation-demo data. — 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

Brisk Customer Receivable Payment Plans list screen displayed with fictional documentation-demo data. — 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

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

Brisk Email Payments create screen displayed with fictional documentation-demo data. — The Email Payments create screen in the Brisk documentation demo.

Select Customer and verify the recipient's email on the customer record.
Enter Amount and a short Memo the customer will recognize. Do not put confidential account or card data in the memo.
Choose the configured Payment Provider and allow card, ACH, or both according to company policy and provider support.
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.
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

Brisk Email Payments detail screen displayed with fictional documentation-demo data. — 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

Brisk Email Payments list screen displayed with fictional documentation-demo data. — 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

Brisk EMV Terminals create screen displayed with fictional documentation-demo data. — 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.

Use a Name that identifies the business location and register, such as “Front Counter 1,” not only the hardware model.
Record the serial number and, where used, MAC address so staff can match Brisk to the device in hand.
Select the correct Payment Provider and enter only the gateway hardware ID or pairing code supplied for this device.
Enable EMV, NFC, tip adjustment, and PIN debit only when both the hardware and business workflow support them.
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

Brisk EMV Terminals detail screen displayed with fictional documentation-demo data. — 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

Brisk EMV Terminals list screen displayed with fictional documentation-demo data. — 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

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

Brisk Payment Plans detail screen displayed with fictional documentation-demo data. — 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

Brisk Payment Plans list screen displayed with fictional documentation-demo data. — 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

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

Brisk Payment Subscriptions detail screen displayed with fictional documentation-demo data. — 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

Brisk Payment Subscriptions list screen displayed with fictional documentation-demo data. — 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.