Payments

Move money with context.

Shape payment intent around the recipient, purpose, policy and authority that should remain visible from creation through the operating record.

Get Started Discuss Treasury

New paymentDraft intent

RecipientNorthstar ServicesKnown counterparty · operating vendor

AmountAmount entered at creationPurposeOperating expense

Policy preflight Approval requiredAuthority is checked before downstream submission.

IntentReviewAuthorizationSubmission

Create a payment

Start with intent, not a transaction ID.

Capture the recipient, purpose and business context before the workflow asks anyone to authorize movement.

RecipientKnown business counterparty

PurposeOperating expense

Supporting contextInvoice and internal note

CounterpartyNorthstar ServicesVendor relationship

Purpose: Operating services
Destination: Reviewed record
Change context: Visible before approval

Counterparty context

Know who sits on the other side.

Payment review is stronger when the recipient relationship, destination context and recent changes are visible beside the request.

Policy preflight

Surface the rule before the approval.

Policy can shape the review without pretending to make the decision. Keep thresholds, destination context and exception signals legible before authorization.

AuthorityApprover required

CounterpartyKnown relationship

ExceptionNo exception raised

Approval request

Operating payment

InitiatorFinance operator

ApproverAuthorized reviewer

Decision contextPolicy + recipient + purpose

Approval records the decision. It does not imply submission or settlement.

Approvals

Decision and movement stay distinct.

Make authority explicit, preserve separation of duties and keep the approval record attached to the intent that was actually reviewed.

Status and progression

One lifecycle. Distinct states.

Track authorization, submission, confirmation and reconciliation as separate operating concepts. The interface should show progression without promising speed or collapsing evidence.

IntentPayment context captured

AuthorizedDecision recorded

SubmittedDownstream movement state

ConfirmedProvider or network evidence

ReconciledRecord matched to authority

Payment record

IntentRecipient + purpose retained

PolicyPreflight context retained

ApprovalDecision actor retained

ProgressionLifecycle evidence separated

Evidence and exceptions

Keep the trail useful after the click.

Preserve what changed, who reviewed it and which evidence belongs to each lifecycle state. Exceptions should return to review instead of disappearing into a generic “complete” state.

Payments

Every payment should carry its authority with it.

Get Started See Treasury

Understand the payment beyond the confirmation screen.

A payment connects purpose, payer, recipient and a sequence of financial events. A reliable record needs to explain that sequence, including uncertainty and exceptions.

Before submission

Review the recipient, amount, currency, purpose, fees and any required approval in a supported workflow. Payment-method availability, merchant eligibility and transaction limits must be established for the specific service; this page does not offer universal payment acceptance.

After submission

Authorization, capture, settlement, refunds and disputes describe different events. If a submission times out, its outcome may be unknown. Check the existing transaction and seek clarification rather than assuming it failed and creating a second payment.

Questions and next steps

Does a success screen prove settlement?: No. A screen or acknowledgment can describe one stage of processing. Settlement and reconciliation require the relevant financial evidence and records.
Does this page establish supported payment methods or merchant pricing?: No. Supported methods, merchant terms, fees and activation requirements must be published for the applicable service before they can be relied on.