# Migration Guide for Existing Clients

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 or batch CAPTUREs** 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.