Authorize a payment
Separate the payment authorization from the later capture decision.
Authorization workflow
Use POST /api/v5/payments/auth to authorize a payment, then capture the authorized payment when the workflow is ready for settlement. Confirm the applicable processor rules and authorization lifetime for your merchant. lifecycle
Token authorization
Use one payment-details variant. This example submits a token and a numeric amount; it does not collect raw card data on your server. POST /api/v5/payments/auth HTTP/1.1 Host: sandbox.nmi.com Authorization: <sandbox-private-key> Content-Type: application/json { "amount": 25.0, "payment_details": { "payment_token": "<fresh-sandbox-token>" } } Sandbox verified 2026-10-16: synthetic-card authorization, full and partial capture, lookup and void passed. Token-based authorization remains a separate test.
Persist the authorization
Keep the returned payment ID alongside your own order and attempt identifiers. Suggested application records: Record Purpose Order ID Links the payment decision to fulfillment. Gateway payment ID Identifies the authorization for later capture. Authorized amount and currency Lets your application check the requested capture. Attempt outcome and timestamps Supports recovery and operational investigation.
Decide the next operation
Recommended workflow: check the authorization outcome, verify fulfillment status, then capture only the amount you intend to collect. If the order is canceled, evaluate a void while the payment is still eligible. Do not create a new sale simply because the capture is delayed. Test an approved authorization with a later full capture. Test a smaller capture amount. Test cancellation before capture. Test loss of the authorization response without blindly repeating payment creation.
Account-dependent behavior
The reference does not establish a universal authorization-expiry duration or a universal policy for repeated partial captures. Confirm those behaviors for the processor before exposing them in your product.