Maintain an existing Collect.js integration
Preserve token collection while modernizing server submissions safely.
Position Collect.js correctly
NMI documents Collect.js for existing integrations and recommends Payment Component with REST for new builds. If your deployed checkout already uses Collect.js, you can migrate the server API without replacing working browser tokenization in the same release. This reduces the number of moving parts in a payment migration.
Treat its token as temporary
Collect.js tokens are single-use and expire 24 hours after creation. They are not saved customer records. Send a freshly collected token to your server for the intended operation; use Customer Vault when the customer agrees to store a method for future use. Need Correct treatment Immediate purchase Collect token, submit once and inspect result Save a card Store through Customer Vault and retain its ID Retry after uncertainty Reconcile first; do not blindly reuse or regenerate and charge Token older than 24 hours Collect a fresh method for the intended action
Change the server payload, not the token contract
For the REST sale endpoint, place the existing Collect.js token under payment_details.payment_token. Move private-key authentication from the classic form body to the Authorization header. Do not send the browser token as an Authorization credential. POST /api/v5/payments/sale HTTP/1.1 Host: sandbox.nmi.com Authorization: <sandbox-private-key> Content-Type: application/json { "amount": 10.00, "payment_details": { "payment_token": "<collectjs-token>" } }
Preserve method and browser coverage
Existing integrations may support cards, eCheck and wallets. Confirm processor compatibility before assuming a method remains available after changing server requests. Apple Pay has domain/account configuration; the presence of a wallet button is only one part of acceptance. Inventory configured methods, callback behavior and validation rules. Capture regression tests for each currently enabled method. Map server fields and responses to the REST contract. Verify the same merchant credentials and environment are used on both sides. Run a limited rollout with duplicate prevention and reconciliation.
Avoid combining unrelated migrations
A new visual checkout, different processor, moved vault and REST migration are separate changes. Roll them out deliberately with distinct evidence and rollback boundaries. Keep classic requests supported for unaffected cohorts until the new path is verified, but never submit the same customer charge through both paths as a comparison test.