Create, update and use vault customers
Keep customer identity, stored credentials and payment outcomes separate.
Create a customer
POST a freshly collected payment token to /api/v5/customers from your server. Keep the private Authorization key outside browser code. Map the returned id to your own authenticated customer; a browser-supplied customer ID does not prove ownership. POST /api/v5/customers HTTP/1.1 Host: sandbox.nmi.com Authorization: <PRIVATE_KEY> Content-Type: application/json { "payment_details": { "payment_token": "<NEW_PAYMENT_TOKEN>" }, "billing_address": { "first_name": "Example", "last_name": "Customer", "email": "customer@example.com" } }
Update or delete an owned record
PUT /api/v5/customers/{customer_id} updates payment_details and billing/shipping address fields. DELETE on the same resource removes the record. Authorize the local customer-to-vault mapping first. Handle an empty successful deletion response without forcing JSON parsing. Operation Verification Create / update Check HTTP result and returned customer id Delete Check the endpoint success status; body may be empty Failure or timeout Retain context and reconcile; do not silently recreate the customer Create customer contract Update customer contract Delete customer contract
Charge a saved method
POST /api/v5/payments/sale with amount and payment_details.customer_vault_id. Calculate amount on the server. Confirm response=1 and retain the payment id before fulfilling; HTTP 200 or a vault id alone is insufficient. { "amount": 10, "payment_details": { "customer_vault_id": "<OWNED_CUSTOMER_ID>" } } Sale contract and language examples Stored-credential linkage
Handle payment replacement and cancellation
Request a fresh token when replacing payment information. Deleting a saved customer is not a documented substitute for canceling every related subscription. Review recurring arrangements separately and retain transaction history needed for reconciliation.