Appmint Merchant Accounts

Written guide

Evidence: merchant UI source checked on 4 October 2026. Images are earlier local form and pending-account captures. Approval, customer permissions, payments and credit enforcement were not newly exercised in this pass.

What you will learn

This course covers Appmint CRM Merchant Accounts. We will create an account for a customer, inspect its lifecycle, manage authorised users and review transactions, invoices and payment records. Recording a payment is not the same as charging a card through a payment provider.

01. Create the account

Merchant Accounts manages a business purchasing/credit relationship and its transactions. Shared Accounts instead manages who may buy on a customer account. Choose the correct module for the relationship you need.

Steps

1. Open CRM → Merchant Accounts → Merchants, then New Merchant.
2. In Account Owner → Customer, search and select the existing customer. Typed text alone is not a linked owner.
3. Enter the required Company Name and optional Trade Name (DBA). Select the intended Account Type; it classifies the merchant account, not your Appmint subscription.
4. Expand Notes if internal context is needed, then select Create Merchant once.
5. Return to Merchants and open the saved account. Compare its owner, company and status. Inspect Settings before approval rather than treating a default credit figure as a considered business decision.

Historical blank form. The disabled Create Merchant action is expected while required inputs are missing.

Check the result

Creation and approval are separate. Do not use an unrelated shared-account member screen as proof of merchant access.

02. Approve and control lifecycle

Pending, Approved, Suspended and Closed have different effects. Suspension is temporary; the close confirmation states that closure cannot be undone.

Steps

1. Open the merchant and read the status badge beside its name.
2. Review Overview, the account owner and Settings before choosing Approve. Approval can notify the customer.
3. After the intended action completes, refresh and inspect History alongside the new status.
4. For a temporary restriction, choose Suspend, enter the reason and confirm. Use Reactivate when that restriction should end; check the resulting state again.
5. Read Close separately. Its confirmation describes permanent closure; do not use it as a reversible pause.

The pending example in the detailed section below shows several lifecycle buttons together. Their visibility does not mean every transition is appropriate from the current state; read the confirmation and response before assuming success.

Check the result

Use a disposable test merchant when practising account closure. Approval/state enforcement must also be checked through the merchant’s actual purchasing surface.

03. Assign authorized users

Authorized Users associates customers with merchant roles. Its User, Manager and Admin roles differ from the Buyer/Manager roles in Shared Accounts.

Steps

1. Open the intended merchant, then its Users tab.
2. Select Add Authorized User and choose the existing Customer who needs access.
3. Choose the intended Role—User, Manager or Admin—and select Add User.
4. Reload Users and match the member by identity. Then use that person's own login to verify permitted actions and restricted records.
5. When removing access, select the intended member and read the removal confirmation. Verify that access has ended in the member's session, not merely that a row vanished from the administrator's view.

Check the result

Owner session visibility does not prove member access. Approval capabilities and transaction scope require the participant’s own verification.

04. Inspect transactions and invoices

Transactions, invoices and balances belong to the same merchant relationship. Compare their identifiers before interpreting outstanding balance or credit.

Steps

Open Overview and read Credit Summary. Open Transactions and the intended transaction details. Open Invoices for the same merchant, inspect its billing period and linked transactions, then compare the displayed total and balance.

Check the result

A display count does not prove a charge or settlement. Use existing authorized records or disposable financial fixtures; no payment should be invented for a success scene.

05. Record payment and reconcile

Record Payment records the payment against the invoice. The result must agree with the invoice and merchant balance; a method label does not itself prove a gateway charge.

Steps

Open the intended invoice and Record Payment. Enter the actual authorized payment amount, method and reference required by the form, then save once. Reload the invoice and merchant Overview and compare the updated balance and history.

Check the result

Use actual authorized payment evidence when recording. Exact amount/reference fields and payment side effects need runtime inspection; do not imply Credit Card selection processes a card payment.

06. Settings, history and recovery

Credit Settings and Internal Notes change account administration. History helps explain who changed the relationship and when.

Steps

Open Settings, review the intended credit change and save. Open History and compare the new entry with the saved value. For a failed operation, refresh the same merchant and inspect its current state before retrying.

Check the result

Closing, suspending and editing credit must be demonstrated on disposable records. Financial reconciliation and enforcement remain live proof requirements.

07. Credit settings and invoice payment records

A merchant account's spending limit, payment terms and billing day control different aspects of account management. Invoice payment entry records money received. It must not be described as a payment-gateway checkout simply because Credit Card appears in the method list.

Steps

Open the merchant's Settings. In Credit Settings, enter Spending Limit, Payment Terms (Days) and Billing Cycle Day. Add Internal Notes where needed and select Save Changes. Reopen Settings and check all values: the UI saves limit, terms and notes through separate operations, so a partial failure needs a field-by-field recheck.

Open Invoices and select the intended invoice. Inspect its invoice number, amount and status before Record Payment. In the payment drawer, review Amount Due, enter Payment Amount, select Payment Method and add Notes containing the payment reference or receipt number. The available methods are Cash, Check, Bank Transfer, Credit Card, Debit Card and Other. Select Record Payment once, then refresh the invoice and merchant overview to inspect payment history, remaining balance and status.

Use Transactions to trace the underlying delivery, order, subscription or credit entry. Open Transaction Details rather than relying on the summary amount. Use invoice and merchant History to connect the operation to its actual record. In the main dashboard inspect the ageing buckets Current, 1–30, 31–60, 61–90 and 90+ Days only after refreshing the saved results.

Check the result

The current terms input substitutes 30 when the value is empty or zero; billing day substitutes 1. Do not teach zero-day terms without verifying the saved value. The payment button is disabled for an empty amount, but the server's handling of overpayment and invalid amounts still needs a controlled test. Record only a payment actually intended for this invoice; if the response is unclear, refresh the payment history before retrying.

Your next check

Return to the chapter for the action you need. When you change the configuration, check the matching record, customer view or destination again. A saved setting and a successful external outcome are different observations.

Detailed creation example and recorded result

This earlier walkthrough preserves the actual pending record and its default settings. Substitute your own owner and company. These images do not establish approval, a purchase, a collected payment or customer access.

Create a pending business purchasing account

Use CRM → Merchant Accounts for B2B account administration. This is separate from selecting a payment gateway: the screen manages business-account ownership, status, credit and billing. Its main areas are Dashboard, Merchants, Transactions and Invoices.

1. Select Merchants, then New Merchant.
2. In Account Owner → Customer, select the existing customer by email. Our example uses Alex Cedar. Choose the actual result; typed search text alone does not establish the customer link.
3. Enter Cedar trade account as Company Name and Cedar & Form as Trade Name (DBA). Company Name is required. Trade Name is optional.
4. Keep Account Type Standard for this example. Premium and Enterprise are available choices; this control is an account classification, not a course claim about Appmint subscription pricing.
5. The Notes section is collapsed by default. Expand it if you need an internal account note; the recorded example leaves it empty.
6. Select Create Merchant. The drawer closes and the list shows Cedar trade account, Pending, standard, balance $0.00 and credit limit $5000.00.
7. Select View. Confirm Account Owner is Alex's email, and Company Name/Trade Name match what you entered.
8. Reload and return to Merchants. The same pending account remains in the list.

Inspect defaults before approval. The create form does not ask for credit terms. The saved record starts with a $5000 limit, NET 30 terms and billing-cycle day 1. These are the recorded application defaults, not a recommendation to extend that amount of credit. Creation leaves the account Pending. Review Settings and the customer relationship before using Approve; approval sends a customer notification. This course capture has not approved the account, posted a charge or sent an invoice.

The detail tabs Overview, Transactions, Invoices, Users, Settings, History separate the account summary from its activity and access. Creating a merchant is not evidence that a transaction occurred. Our balances and transaction counts remain zero.

Verification notes