Migration Guide for Existing Clients

Copy

• Copy for LLM

  Copy page as Markdown for LLMs
• View as Markdown

  Open this page as Markdown
• Open in ChatGPT

  Get insights from ChatGPT
• Open in Claude

  Get insights from Claude

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.

Key Field Changes

🔁 originalPaymentTransactionId

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 REFUND transaction, if you have a previously assigned <GatewayTransactionId>, you may use that value in this field.

• Existing ACH processing clients:
  When sending an ACH_REFUND transaction, 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.

🔁 credentialsOnFile.sourceEntityParams

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.

💡 Tip: This field is flexible—use it to maintain continuity with your legacy recurring logic while adopting the new API structure.

🧠 Migration Tip

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.