Skip to main content

Virtual Terminal, Invoices, and Document Builder

These pages handle three different workflows:

  • Virtual Terminal creates a keyed sale or authorization for the selected store.
  • Invoices creates and tracks customer receivables for the selected store.
  • Document Builder manages invoice and receipt layouts for the organization.

Use the organization and store selectors before starting. Never use Virtual Terminal as a substitute for an invoice when you need to send a balance for later payment.

Virtual Terminal​

Virtual Terminal is for card-not-present or manually keyed transactions explicitly supported by the portal:

  • phone orders;
  • mail orders; and
  • keyed in-person sales when a reader is unavailable.

The page requires store.transactions.read, store.transactions.write, and store.products.read for the selected store. Without all three permissions, Virtual Terminal is unavailable, including through a direct link. Store cashiers do not need org.categories.read or access to tax settings: checkout loads only active, Gateway-mapped category names and codes through the selected store's checkout access. A completed sale appears in Sales & Payments and moves inventory like a sale completed at a register.

Catalog lines send only the selected product and quantity. The server resolves the active store-scoped catalog price, tax, deposits, and totals; cart figures before preparation are provisional. Ordinary custom lines and catalog price changes require a persisted server price approval issued by an authenticated manager with store.products.write and their own price-override delegation. The server validates the approval's store, actor, quantity, currency, current catalog snapshot, expiry, and quote identity. Manual lines use the server's General Merchandise tax treatment rather than a caller-selected exemption. Selling a gift-card denomination uses the separate gift-issuance permission and policy, not ordinary manual-price approval.

Key a sale​

  1. Confirm the selected store and open Store Operations > Virtual Terminal.
  2. In 1. Items, search for products by name or barcode and add them to the cart. For an ordinary custom line, enter its description and amount and obtain the required server price approval.
  3. Review quantity and the provisional catalog price for each line. Price changes require the same approved override workflow; entering a different number does not change a catalog charge by itself.
  4. In 2. Customer & tax, attach the customer or explicitly continue without one when those controls are available to your role. An attached customer's saved tax address and exemptions can affect the quote; a city or state entered under Tax destination overrides that saved destination. Customer search accepts only identifiers enabled by the store: phone, email, loyalty ID, or barcode. Customer association is available even when loyalty prompting is off. With both Customer read and write permission, New Customer checks the selected permitted phone or email first, attaches an exact existing match, and enrolls only after a lookup miss. Names are optional; profile editing and marketing consent belong in Customer management. Ambiguous identities must be resolved there before attachment. US phone lookup treats ten national digits and the equivalent eleven-digit number prefixed with 1 as the same identity without rewriting saved profiles; if separate profiles match those forms, the identity remains ambiguous.
  5. Choose how the card was received: Phone order, Mail order, or Keyed in person.
  6. Enter the card number, expiration, and security code only in Peak Gateway's embedded secure card fields. Enter the cardholder name and billing address in the Virtual Terminal's corresponding fields. Do not save card details in notes, screenshots, email, or another customer field.
  7. Enter an email or phone under 4. Receipt & confirm when the customer should receive a receipt. Add an order reference that will help staff identify the sale later; the customer sees it on their receipt. Use Internal note for anything only staff should read.
  8. Prepare the payment to obtain authoritative pricing and tax for the current selections. If you change an item, customer, destination, tip, reference, or payment detail, obtain a fresh quote. Retrying delivery of the same quote attempt returns its original immutable price, even if the catalog subsequently changes; a new explicit attempt uses current pricing.
  9. Choose an action:
    • Charge now completes the sale immediately.
    • Authorize only — hold the funds, capture when it ships reserves the amount for later capture.
  10. When secure checkout is ready, select the Retail Charge now or Authorize only button once to submit the quoted payment.
  11. Wait for Payment approved or Authorization approved. For an authorization, select Capture now only when it should be completed.
  12. Select View in Sales & Payments and confirm the resulting transaction.

If the page reports Payment requested or an unknown outcome after payment dispatch, the original intent remains available separately for status and recovery. It does not lock a new, unrelated cart. Use the original intent's recovery action; never assume an unknown result failed or enter the same purchase as a fresh payment merely to retry delivery.

Hosted-session creation is fenced before Gateway is called: the original intent and a high-severity Action Inbox review item are recorded first. If the create response is lost before a session ID is returned, the original attempt stays pending review and Gateway create is not retried. Do not start another checkout for that purchase or treat local expiry as proof that no session was created. Reconcile the original review; unrelated carts remain available.

A definitive decline of a customer's saved card ends that checkout as failed and releases any reserved reward points. Reopening or retrying the same checkout preserves its original decline; it does not charge the card again. A lost or ambiguous payment response remains in recovery, with its reward reservation retained until the original outcome is known. Older responses that do not establish whether an amount was processed also remain in recovery rather than releasing rewards prematurely.

Where gift-card and keyed-card split checkout is enabled, completion keeps one sale with the quoted gift/card amounts and any quoted coupon link. Recovery uses that original quote and transaction; it does not replace the coupon or create another sale.

Gift-card allocation, mixed-tender availability, reward combinations, saved-card availability, and authorization eligibility come from the server quote. A gift denomination is not merchandise or a tip: the server excludes it from reward discounts and tax basis and binds issuance to the quoted denomination, not the complete basket total.

Invoices​

The Invoices navigation entry is available to roles with invoicing read, write, or administrator access. The list itself is scoped to the selected store. Actions require narrower permissions:

  • invoicing.invoices.write creates and edits drafts, issues and sends invoices, and manages saved invoice items;
  • invoicing.payments.write records payments, creates payment links, and handles eligible refunds; and
  • invoicing.invoices.admin enables invoice administration such as voiding and defaults management.

Find and track an invoice​

  1. Confirm the selected store and open Store Operations > Invoices.
  2. Search by invoice number, customer name, or notes.
  3. Filter by status: Draft, Sent, Partially Paid, Paid, Overdue, Uncollectible, or Voided.
  4. Review the due date, total, paid amount, and outstanding balance.
  5. Select the invoice to open its detail.
  6. In the detail, review:
    • invoice status, customer, due date, line items, discounts, delivery fee, and totals;
    • Delivery status, including destination, provider outcome, failure reason, and attempt count;
    • Payments and any recorded refunds;
    • Activity Timeline for status changes and other invoice events; and
    • Last Sent and first-viewed information when recorded.
  7. Use PDF to preview or download the customer document.

The customer invoice shows its line items before totals, then the payment schedule. Remaining balance and Due now are distinct server-calculated amounts; Next payment shows its scheduled amount and due date. Unpaid invoices keep plain schedule rows without progress bars. Once payments or credits are recorded, the invoice and affected stages show accessible progress; cash paid and credited amounts remain distinct, and excess credit appears as account credit. The payment amount choices and single Pay button appear separately below the invoice document. A future balance does not make the full outstanding amount due now.

Invoices created from a quote show Created from Quote and its number. In the merchant portal, select that number to return to the source quote; the converted quote links back to the invoice by number (or to the draft before an invoice number is assigned).

Customers revisiting an accepted quote see its conversion date and the invoice's current outstanding balance. View / Pay Invoice opens the numbered invoice when it is payable; after full payment or voiding, the link becomes View Invoice. The original quote total remains unchanged. The customer invoice also identifies the source quote by number.

A successful send is queued for delivery; it is not proof that the customer received it. Return to Delivery status and check the provider outcome. Authorized invoice writers can retry a delivery marked failed.

Invoice delivery retries refer to the original durable delivery ID. If a send response is interrupted before that ID is visible, retry the same send identity instead of starting another delivery. Queued or processing delivery remains pending; only the provider's delivery result confirms receipt.

Invoice detail and list reads provide server-calculated action availability for issue, send, void, record payment, payment link, refund, and credit note. Refund availability and tender-specific capacity account for existing refund reservations; invoice credits and payments are not treated as interchangeable. A pending payment outcome is shown by the server's payment admission state, rather than inferred from client status or a locally calculated balance. Actions still revalidate current state when submitted.

A single keyed send can queue both email and SMS. Its response identifies only that send's durable delivery rows, including their IDs and statuses. Retrying the same identity preserves both rows and rejects changes to recipients, customer name, message, or channel selection; use a new send identity for a different delivery request.

Completed actions recorded before delivery receipts were included still replay with their original identity and financial snapshot. For an older send whose exact delivery rows cannot be proven, the response explicitly reports deliveryIdentityKnown=false and an empty receipt list. This is an unknown delivery association, not proof of failure or permission to retry another delivery from the invoice's history. Keep the original send identity and use delivery-history readback for investigation rather than automatically sending again.

Invoice reads preserve the stored historical customer identity. If that snapshot is corrupt, detail, list, and assistant search report an explicit integrity error instead of substituting the customer's current name or contact details. Valid older snapshots still support absent fields and legacy names; an explicitly empty or null field is not replaced with live customer data. Corrupt records require investigation rather than silently changing the document.

Hosted invoice checkout may prefill the customer's name, email, phone, and billing street from the details already captured on the invoice. Those values stay with the original hosted checkout attempt: retrying or resuming it does not refresh them from the customer's current profile, and existing customer details in checkout are not overwritten. These are suggestions for checkout only; they do not verify who is paying or authorize a charge.

On the customer invoice, select Pay due now or an available Pay full balance option in the payment amount card. The single Pay button follows that selection and opens secure hosted checkout. Full-balance payment requires invoice policy to permit paying ahead and the server to admit that amount safely; an existing session may leave only its verified original amount available until safe replacement can be proved. Permitted custom amounts are available under Pay a different amount. An existing checkout for the same amount is reused without a separate reopen or continue choice. Opening checkout does not itself mean a payment was submitted. If checkout could not be confirmed, use the same amount's Pay action to retry delivery of the original request; do not assume an interrupted response means no checkout exists. Any support reference is copyable, while internal error codes and HTTP status are not displayed on the customer page.

When no amount is currently due and a future scheduled payment is available, the scheduled choice is labeled Pay next payment, not Pay due now. Custom amounts must be positive, use the invoice currency's precision, meet the displayed minimum, and not exceed the remaining balance. The server revalidates these bounds and payment policy when checkout starts.

If the only safe action is resuming a verified existing checkout whose original amount differs from the current scheduled and full-balance amounts, the invoice shows one Pay button for that exact original amount, without an amount chooser or custom input. This preserves the existing checkout's immutable amount even if the merchant has since raised the minimum or disabled new custom payments; it does not authorize a new amount. Required authorization, submitted-payment uncertainty, and provider funding checks still block unsafe payment admission.

After returning from hosted checkout, the customer invoice refreshes its server status every 2.5 seconds while the returned payment is unresolved, for up to one minute. The same bounded refresh applies when payment admission reports a pending outcome. Refreshing stops when the invoice is paid or terminal; a recorded partial payment resolves the hosted return unless another outcome remains pending. Refresh remains available after automatic checks stop and does not start or replace a payment.

The public invoice page does not enroll, replace, remove, select, or newly charge saved cards, and does not create Auto-Pay authorizations. Those invoice-link setup and authorization operations have been retired. New customer invoice payments start through hosted checkout only. Card saving is off for this guest checkout because a verified customer binding and supported guest-save capability have not been established; the invoice does not send a save-card request flag. An invoice requiring a saved-card authorization directs the customer to contact the business rather than bypassing that policy. Merchant payment-profile and Auto-Pay settings remain separate.

Revoking a payment link remains a safety operation even for a corrupt snapshot: active tokens and pending deliveries are revoked. If the refreshed document cannot be read, the integrity error explicitly confirms that the payment link was revoked; it does not mean that the old token remains usable.

Create and send an invoice​

  1. Select New Invoice.
  2. Choose the customer and due date.
  3. Add each product, saved invoice item, or manual line. A manual line must have a category.
  4. Review quantity, unit amount, discounts, delivery fee, terms, footer, and notes.
  5. Save the draft and open its detail.
  6. Select Send.
  7. Confirm the customer name and enter at least an email address or phone number. Add a message if needed.
  8. Select Issue and Send Invoice for a draft, or Send Invoice for an already issued invoice.
  9. Reopen the invoice and verify its status and delivery result.

Draft creation is separate from issue and delivery: a draft can be saved without a due date or delivery contact. Issuing requires valid invoice lines and a positive server-calculated balance; sending requires an eligible issued invoice and a recipient. Invoice and quote editors obtain canonical totals, tax, discounts, and payment-stage amounts from the server. Product-reference invoice lines use the selected store's currency and the server-authorized catalog price, rather than a price copied from a client cache.

On iOS, Save offline retains draft-only intent: synchronization creates the draft without issuing it or reducing stock. Submit online retains a separate explicit issue choice for later synchronization if interrupted. Older queued records without a known issue choice remain drafts and keep their original invoice identity.

Android's online create-and-send flow saves the draft first, then submits authenticated POST /invoices/{invoiceId}/issue-and-send in the existing scoped invoicing route. The server issues an eligible draft and queues delivery in the same transaction; an already issued invoice is delivered without issuing again. This intent uses the original logical send action key and body fingerprint, including original deterministic delivery IDs. A key previously submitted to /send replays its historical receipt before any issue, stock movement, or new delivery, even after switching endpoints. The existing /send endpoint remains delivery-only: drafts use canIssue, not canSend. Creating without contact or synchronizing an offline draft never implicitly issues or sends it.

Draft and quote editors use POST /api/v1/orgs/{orgId}/invoicing/invoices/draft-preview?storeId={storeId} with invoice-write authorization and the same store-scoped invoice creation intent. The body store must match the authorized query store. Its response supplies the currency, subtotal, discount total, delivery fee, tax total, collectible total, per-line financials, and resolved payment schedule. Preview does not save a draft, create a walk-in customer, or repair tax identities. Without a selected customer it calculates tax at the store address with no customer exemption. An existing draft preview can supply invoiceId and each item's sourceLineId to reuse that draft line's authorized category while recalculating edited amounts; foreign draft or line references are rejected.

For invoice drafts, the server normalizes submitted line quantities to four decimal places with HALF_UP for both preview and save, rejecting quantities that normalize to zero or below. Use the preview's canonical quantity and per-line financials in the editor; do not round the raw input or recalculate those values locally.

New quote draft quantities are normalized by the server to four decimal places with HALF_UP in preview and draft create/full replacement and line add/update/delete, before validation, tax, and line financials; quantities that normalize to zero or below are rejected. Use the quote preview's canonical quantities and per-line financials rather than rounding raw input or calculating them locally. This applies only to new quote draft input: published or accepted quote snapshots and existing quote-to-invoice conversion behavior remain unchanged.

Catalog invoice lines can submit only posProductId (the POS product UUID) and quantity. The server resolves an active product in the selected organization and store, derives its name, category, SKU, price, and store currency, and ignores caller-authored catalog description, category, and unit amount. A conflicting currency is rejected. Manual lines still require a description, unit amount, and authorized product/category or billing-code attribution; line discounts, invoice discounts, tax exemptions, and schedule timing remain server-validated. Relative payment dates remain unresolved until issue, rather than being replaced by a client guess.

Draft replacement, line addition, and line updates carry the same explicit posProductId catalog intent and resolve the current catalog price on save as on preview. An inventoryItemId without posProductId retains the existing manually entered price policy and uses the inventory product for tax attribution only. Editable draft previews honor the submitted exemption toggle, including removal of a previously saved manual exemption; unchanged issue previews explicitly preserve the saved manual intent. Quote previews use the quote's own save intent rather than introducing catalog pricing that quote writes do not apply.

Payment-schedule edits for existing drafts and issued invoices use POST /api/v1/orgs/{orgId}/invoicing/invoices/{invoiceId}/schedule-preview?storeId={storeId} with the schedule-save intent (currency, milestones, optional allowPartialPayments). This preview resolves stages against the stored collectible total and original issue date without recalculating tax or changing the document. It preserves payment-locked stages and rejects foreign stage IDs, invalid timing, and schedules that do not cover the total. Saving revalidates under the invoice lock and refuses to change the schedule while a payment outcome is pending.

Accepted payment methods in Invoice Settings controls the defaults for new invoices. Each invoice stores its own selection; the draft editor can override it without changing the merchant defaults or existing invoices. Uncheck Card to disable online payment. Customers can still view the document, but cannot open a hosted checkout. The ACH option is disabled because invoice checkout is currently unavailable for ACH: Gateway must first provide authoritative tender, pending/settlement, failure and bank-return reporting. A saved ACH preference never authorizes or enables ACH charges. Card checkout also requires current Gateway merchant policy and capability authorization; invoice settings never grant payment capabilities. Currently, Gateway must prove an explicit operational card-not-present route. Default-only routing remains unavailable until Gateway publishes its effective location routing authority (integration issue #5630), even if Card is selected in Invoice Settings. Changing that selection does not create Gateway authority. Invoice document links, delivery and reminders remain available independently of online card availability. With payment-management permission, Payment Link still generates or copies the view-only invoice link when online methods are disabled; opening that document never overrides the checkout authorization checks. Scheduled, full-balance and custom payment choices remain subject to the current server capability projection; invoice policy alone does not authorize replacing an unresolved or funded checkout.

Reuse an invoice configuration​

From New Invoice, open Reusable templates to manage configurations for the selected store. These are separate from PDF layouts in Document Builder.

  • Use Save current invoice as template to copy the current products/services, descriptions, payment structure, terms, notes, discounts, delivery and tax intent into an isolated editor, or start with New template.
  • Give it a Template name and choose Save template. Edit and Delete are explicit operations; stale changes require reloading the saved template before another write.
  • Use copies a saved configuration into the current invoice without changing its customer. Invoice edits afterward never update the template or merchant defaults.
  • Optional Starter templates provide Contractor / Project, Professional Services and Standard Invoice structures. Customize them with real products/services and prices; starters are not mandatory defaults.

Leading fixed amounts stay fixed and percentages are calculated against the new invoice total. The final stage is the remaining balance. Calendar dates are saved as days after invoice issue, and overall due timing is reused relative to the new invoice. Tax is calculated from the selected store, product/category and customer at invoice save; templates do not freeze tax totals or reuse customer exemption certificates.

Reminder configuration can inherit the current merchant cadence separately for each new invoice or copy an explicit template override, including reminders disabled. Later invoice changes do not mutate the template or organization settings.

Collect and reconcile an invoice​

With payment write access, open an eligible invoice and use:

  • Record Payment to record an amount, received date, method, and reference; or
  • Payment Link to create a link for the customer.

After collection, confirm that the Paid and Outstanding amounts, invoice status, payment row, and activity timeline agree. Use Refund only when the invoice and payment are eligible. After resolving a definitive provider rejection, a new refund request can use the released balance. If the provider outcome is uncertain, the amount remains reserved until reconciliation; do not submit another refund for it in the meantime. Invoice administrators can use Void when the invoice is in a voidable state.

Action buttons and refundable capacity by tender come from the current server invoice projection. Payment admission is shared across saved-card, hosted-card, gift-card, manual, and Auto-Pay operations. The server retains each attempt and prevents conflicting payment rails from collecting the same balance while an outcome is pending. Retry an interrupted attempt with its original identity; a distinct explicit attempt has a new identity. Pending work on one invoice does not prevent creating or editing another invoice.

An unresolved hosted checkout creation or unavailable status inquiry can block new payment options without proving that a payment was submitted. The customer page shows payment being confirmed only for server-confirmed submitted-payment uncertainty; an attempt explicitly requiring review directs the customer to contact the business. Do not start another payment method or assume elapsed time means an unresolved attempt failed. A new checkout is not started automatically while the original attempt remains unresolved.

Retry payment delivery reuses the original manual payment's amount, currency, received date, method, reference, and request identity after reload. Those fields stay fixed for a retry; the current outstanding balance is not a replacement request. Older recovery records without those fields require exact original-detail reentry before replay. Gift-card codes are never stored with browser retry records.

Gift-card recovery first inquires for the original scoped redemption. A confirmed debit is applied without redeeming again, even if the card expires, gift-card acceptance changes, or the store's payment binding changes after submission. The original payment location is retained before submission and is never replaced during retry. An uncertain inquiry remains pending; new redemptions still require current card and tender eligibility.

A Gateway insufficient-balance rejection is not by itself confirmation that no gift-card debit occurred. The system checks the original redemption record: a found redemption is applied normally, while only a successful check confirming no redemption marks that attempt failed and makes the invoice available for another payment. If the check is unavailable or the provider response is otherwise uncertain, the payment remains pending for recovery; do not submit another payment until its outcome is resolved.

Each settled invoice installment is a purchase, with its actual tender retained. Partially refunded purchases remain in gross customer spend and visit totals; their refund entries are tracked separately. Gateway invoice receipts use the persisted completion event's time, including for captures made after authorization. Eligible Loyalty earning uses the amount actually applied to the invoice, excluding automatically refunded excess. Historical or racing Loyalty awards whose original amount cannot be verified require review: they are not automatically activated, reversed, or recalculated.

On a customer's invoice link, one payment area and one Pay button are used on desktop and mobile. Opening a different invoice link shows its loading state instead of the previous invoice, and late responses from the previous link cannot change the current invoice or redirect it into the old checkout. Leaving a link cancels that page's pending status checks, not a payment already sent to the provider. If a checkout result is uncertain, confirm the invoice's payment history and outstanding balance before starting another payment.

Automatic checkout delivery recovery is bound to the original invoice link, currency, and displayed amount in currency minor units, not just the Scheduled or Full Balance option name. A changed due amount or a regenerated link never silently adopts the old request identity. Unmatched recovery records remain separate; a newly scoped request still requires current server admission or verified safe replacement. Browser persistence stores a hash of the link scope, not the bearer token.

Historical saved-card payments remain available for status inquiry and exact original-request recovery. The retained public payment-profile delivery operation accepts only a previously recorded durable request identity and immutable body; an unknown identity is rejected before a new dispatch. Recovery never enrolls a card, creates an Auto-Pay authorization, or turns the current invoice balance into a new saved-card charge. Prior outcome and required-policy reads remain available independently of new hosted-payment admission.

Customer SDK migration for this intentional breaking release:

  • PublicAccountInvoicePayload.autoPayRequired is now required. Consume the server's policy evidence rather than defaulting an absent value to false; missing evidence must not authorize new checkout. REQUIRED policy does not become optional when enrollment or the dispatcher is unavailable.
  • payCapabilities.resumableAmount is a required nullable amount in the invoice currency. A non-null verified amount can enable one fixed Pay action when ordinary options are empty; use the existing resumeHostedCheckout: true request without option or amount. It is not permission to submit a new CUSTOM amount, and a retained original request must keep its original scoped identity and body.
  • Remove calls to PublicInvoiceAutoPayApi.authorize and its retired authorization request/response models. Public invoice links no longer create Auto-Pay consent.
  • Remove calls to PublicInvoicePaymentProfileApi.setup, setupStatus, and remove, and the retired setup/removal request/response models. Do not substitute another saved-card enrollment or removal route.
  • New public invoice payments use the existing invoice Pay hosted-checkout flow. The retained saved-payment operation is recovery-only for an already recorded immutable request; it is not a replacement for new saved-card charging.

Refreshing an invoice link retains the provider payment identity. If a checkout is marked VOIDED but Gateway inquiry cannot prove a full reversal, the same invoice does not automatically start a replacement debit. Contact the business to reconcile the original attempt before retrying; a status label alone is not proof that no funding remains.

For a refreshed invoice link, the server can authorize replacing a verified unfunded checkout whose return link is obsolete. Replacement cancels and confirms closure of the original session before creating another; saved-card and other rails stay fenced during that process. The browser removes a retained checkout identity only when the server identifies that original request or its alias as ended, never merely because time passed or a response was interrupted.

The public invoice-message POST has been retired, along with the customer SDK's postMessage operation. Its former success response never stored or delivered a message. Invoice viewing, payment, and quote operations remain available; contact the business through its established contact channel instead of treating an API echo as delivery. Integrations must remove calls to the retired operation when adopting the breaking customer SDK release.

The Export receivables panel is organization-wide even though the invoice list is store-scoped. Choose a date range and use Download CSV preview for a local check. Authorized invoice writers can also Generate export and review its status and row count under Recent exports.

Document Builder​

Open Store Operations > Document Builder to manage layouts shared by the organization. The page is feature-gated and requires invoicing access. It is not tied to the currently selected store.

The current builder exposes:

  • Invoice templates used by invoice PDFs; and
  • Receipt templates used by hosted, email, and thermal receipts.

To update a layout:

  1. Open an existing template or select New Template.
  2. Choose the document kind and name.
  3. Edit the template source and use the live preview.
  4. Add every section or receipt token identified as required.
  5. Select Preview PDF and inspect the sample output.
  6. Select Save. Saving a built-in template creates an editable copy rather than changing the built-in layout.
  7. Return to the list and select Set default when the template is valid and eligible.

The list identifies built-in, default, active, and preview-only states. Duplicate a template before making a substantially different version. Do not delete the active layout until another valid default is ready.

For transaction-level verification after a keyed sale, use Sales & Payments. For terminal or payment-provisioning failures, follow Terminals and Troubleshooting.