Management Portal

Access and organization selection

Sign in to the Management Portal with your assigned account. Available organizations, locations, and actions depend on your permissions. Request missing access from your access owner; do not share credentials or assume that visibility grants permission to change processing.

1. Open Organizations and select the organization named in the support case.
2. Confirm the affected location belongs to it. Keep that location selected for transaction and settlement work; a processor merchant ID is not a location ID.
3. Review the organization checklist: selected default credential profile, active profile, pending approvals, active locations, and aligned assignments. An incomplete checklist requires the responsible onboarding owner, not a support workaround or an unapproved activation.
4. Use organization-detail Operator Shortcuts for Event Log, Gift Cards, and Tax Configs. These carry the organization selection into the next view. Reconfirm scope before acting.

Card-not-present billing setup reminders

While an active organization has card-not-present processing enabled but no active ACH billing bank account, its active attributed agent contact and all active agent administrators receive up to four reminders: at grant, once after first approved card-not-present use, and then at seven-day intervals after the first-use reminder. There are no weekly reminders before first use. A delayed grant reminder does not replace the first-use reminder. Billing setup, grant revocation, or organization deactivation stops reminders. Without an active agent recipient, reminders go to the configured support inbox, or the durable operations log if no inbox is set.

First-use and weekly slots require currently verified approval timing. A stored billing date does not override newly ambiguous legacy use: those reminders wait without consuming slots until independent timing evidence resolves the ambiguity. The independent grant reminder remains eligible.

The reminder links to the exact organization's detail page in the agent portal. Confirm the organization and coordinate billing setup with Peak support. Opening the merchant gateway, including through an audited read-write impersonation session, does not authorize billing-bank changes: merchant Billing shows only masked, read-only status. Gateway platform support maintains the account from the support portal's organization-specific Billing page with billing-bank-account:write, a nonblank audit reason, and attestation that the merchant's authorization is on file. This applies to enrollment, replacement, and removal; callers do not choose the server-owned mandate version.

If platform ACH collection is unconfigured, no reminder slots are consumed. Instead, one aggregate warning per UTC day is retained in the operations outbox, including when affected organizations are not due or have reached their cap. The daily sweep filters billed and non-due organizations before paging and persists its continuation after each page, so a bounded run resumes past failing due organizations rather than repeatedly scanning the same prefix.

Transaction and fraud investigation

Search using location, date range, amount, status, or masked card details. Compare the transaction lifecycle and available authorization balance before requesting an authorized capture, void, or refund. An unknown response may mean the processor executed the payment: escalate for reconciliation, never replay the payment just to discover its result.

For merchant Virtual Terminal cases, search by customer name, email, or phone, including customers beyond the initially loaded list. Choosing a customer prefills the available name, billing address, and separate shipping address without replacing operator edits. Search for active catalog products with active one-time prices; add multiple prices or select the same price again to increase its quantity. Change quantities or remove lines before submitting. A manually entered sale amount replaces the cart, so review the purchase summary and total, including per-item tax and any tip, before charging. When inclusive and exclusive prices mix, the tax total shows the portions already included in item prices and added to the subtotal separately; only the added portion increases the amount charged. The displayed purchase summary comes from an immutable server quote, not browser tax or total calculations. Gateway resolves each selected price and product at the authorized location, uses the product rate or the location's configured tax provider, and calculates inclusive/exclusive allocations and the untaxed tip. An explicit per-sale tax override requires the interactive transaction permission and a reason; its rate, treatment, and reason are frozen with that quote. Keyed Sale/Auth/Force Auth and device Sale/Auth bind the quote to one payment reference before dispatch. Retrying that identity keeps its original quote even if catalog prices or tax settings change. A quote cannot authorize another payment reference. Starting a genuinely distinct sale obtains a fresh quote; it does not resolve or forget an earlier unknown payment. Force Auth cannot combine catalog Level 3 lines with a tip on its original provider request; remove the tip or choose Sale/Auth Only instead.

The card sale sends shipping ZIP/postal code and, for catalog lines, a valid two- or three-letter ISO country code; the TransIT adapter sends ISO alpha-3. Shipping street, city, and state are not sent to the processor. The Gateway transaction keeps all selected catalog lines for keyed and saved-card payments. ACH also accepts the cart into Gateway, but ACH processor requests do not carry itemized Level 3 detail or a separate tax amount.

Bolt Cloud Terminal accepts catalog lines with its Gateway payment request and records them on the transaction after the terminal responds, but the original Bolt terminal authorization carries only the total, not processor Level 3 item detail. The NEXGO Cloud Terminal payment adapter is not currently available on this route; the separate NEXGO device checkout does not send provider Level 3 on its original amount-only payment request. Do not promise processor Level 3 for either terminal route. An invalid card number is blocked before submission. Declines show the sanitized host response code and message; an unknown outcome still requires reconciliation, not a second payment attempt.

Selecting Refund closes transaction details and opens a separate confirmation. Cancel returns to the transaction list without submitting a refund; reopen the transaction to review it again before confirming.

In Fraud Engine, confirm the selected organization. Merchant and location users have different permissions; a location view does not grant organization-wide changes. Cross-organization queues require separate platform access.

Payments flagged for review remain authorizations until explicitly captured or voided. The review dialog hides those actions when the available authorization balance is missing or exhausted. Resolving a fraud review is not a capture or a void. An ambiguous payment remains unresolved.

Sanitized fraud score

The transaction score is descriptive, not processor approval or approval rate. A valid available score is an integer from 0 to 100 for the exact organization, location, and transaction. Missing, insufficient, unknown, malformed, or mismatched data must display Unavailable, not an invented number or zero. Do not expose raw signals, provider payloads, thresholds, fingerprints, card data, or credentials. This view is for authorized users, not shoppers.

Approval Rate Protection

Open Fraud Engine > Settings > Approval Rate Protection for the organization under investigation. Confirm whether the selected scope is Organization or one Processor profile before changing anything.

Only qualifying authorization attempts with approved or declined outcomes count. Refunds, voids, captures, settlement, reversals, setup verification, and infrastructure/configuration/validation failures are not processor declines. A restriction blocks qualifying new authorizations and setup verification; follow-on operations such as voids and reversals remain available.

1. Compare the configured rolling window with Past Hour, Past Day, Past Week, and Past Month. A missing rate is not zero percent: there may be no qualifying attempts. The configured minimum sample must be reached.
2. Review recent decline contributors, restriction evidence, and change history.
3. Address the decline cause before requesting restoration.
4. An authorized restore requires an investigation reason and the current version. Refresh and reassess if the version has changed.
5. Monitor the new sample after restore. Earlier attempts are excluded from the rebased evaluation; the configured minimum must accrue again.

Restrictions are sticky: a better rolling rate does not clear them automatically. Only an explicit policy disable or manual restore clears a restriction. Neither is a routine support bypass; retain the reason and follow your approval process.

Settlement and reporting

The Settlement Batches view reads report-backed batches for one selected location from /api/v1/settlements/batches, with cursor pagination. Its status filter and CSV export cover only the current page. SETTLED and REVIEW_REQUIRED need different follow-through; RECONCILIATION_MISMATCH and FORCE_CLOSED describe retained historical records. A confirmed close command is not a confirmed settlement report. No retry, force-close, or adjudication action exists on a batch record.

Manual processor batch close

This requests a real processor action, not a report refresh. Obtain authorization and confirm both the location selection and the destructive confirmation:

1. Select the exact location and click Manual processor batch close.
2. Read and confirm the dialog: one close is requested, and an unknown result must not be retried. If the location or intent is wrong, cancel.

Interpret the result conservatively:

• CONFIRMED: the processor confirmed the close; obtain later settlement report evidence before saying funds settled.
• REJECTED: the processor explicitly rejected the close before execution.
• UNKNOWN: it may have executed. Do not redial or retry. Escalate for exact report evidence and reconciliation.
• Failed, incomplete, conflicting, or unpersisted requests are failed or not confirmed, not proof that nothing happened. Verify before further action.

Record safe location/transaction/batch references and times with timezone. Never attach bearer tokens, full PAN/CVV, or raw processor payloads to a case.

See webhook triage, gift-card support, and tax support.