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. 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 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. 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 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. 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 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. 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 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.