This section provides guidance for clients migrating from legacy CryptPay Direct API to NPS Payments API. It explains key field changes and operational considerations to ensure a smooth transition.
Identifies the original transaction being referenced. The requirement for this field depends on the transactionType.
Here’s how to populate originalPaymentTransactionId in refund-related scenarios:
Existing card processing clients:
- When sending a
REFUNDtransaction, if you have a previously assigned<GatewayTransactionId>, you may use that value in this field.
- When sending a
Existing ACH processing clients:
When sending anACH_REFUNDtransaction, if you have a previously assigned<CryptpayTransactionId>, you may use that value in this field.
This guidance applies only to refund transactions. All other transaction types (e.g.,
CAPTURE,CANCEL,VOID) are subject to time-based restrictions and typically cannot reference legacy transactions after migration. Validate that refunds are accepted using legacy IDs before going live.
Used to group a set of recurring transactions. Accepts any name/value pairs.
Existing clients:
If you previously used identifiers like AppId, PlanId, or similar to track recurring series, continue sending those in this array. The system will recognize and group transactions accordingly.
This field is flexible—use it to maintain continuity with your legacy recurring logic while adopting the new API structure.
Clients who perform delayed POST-AUTHs should ensure all post-auths are completed before switching to the new API. Transactions initiated in the old system should be finalized prior to migration.