Change status before or after renewal activation

This flow applies to a physical card renewed through Card Renewal V2 with card_action=2, the same card product, and the same PAN and token.

• Use action: 1 to change the current card status. Before renewal activation, this keeps the current expiry and does not change the status stored for the pending renewal.
• Use action: 2 when you are ready to activate the pending renewal. Banking.Live applies the new expiry and the status stored during renewal, even if you supply a different status_nwk in the activation request.

For action: 2, you must still supply a valid status_nwk because the API validates this required field. When activating a pending renewal, the supplied value does not determine the resulting network status; Banking.Live applies the status saved during renewal. The "1000" value in the activation examples satisfies validation and does not override the saved status. To change the status after activation, send a separate request with action: 1.

Activation and setting an operational status are separate behaviors. A successful activation can leave the card at 1005 if that was the status stored during renewal.

Recover from a renewal submitted with status 1005

If you want to restore the current card before activating the renewal:

1. Call this endpoint with the same token, action: 1, and status_nwk: "1000". This restores the current network status without applying the new expiry. The card remains subject to its current expiry and other authorization checks.
2. When you are ready to activate the renewal, call this endpoint with action: 2 and status_nwk: "1000". The new expiry is applied, but the status becomes the stored renewal status, 1005.
3. After activation succeeds, send a separate request with action: 1 and status_nwk: "1000" to make the renewed card operational.

If you are ready to activate immediately, start at step 2. If you have already activated the renewal and its status is still 1005, use step 3. Use a new api_call_unique_identifier for each separate operation.

The request field status_nwk is a string. For action: 2, the response reports the resulting network status as an integer; check this value rather than assuming that the requested status was applied.

Results and retries

Treat header.error_id: 0 as success. HTTP 200 alone does not confirm that the operation succeeded. If header.error_id is nonzero, stop the dependent call sequence and inspect header.error_desc before deciding whether to retry or correct the request.

After a timeout, HTTP 500, or a lost response, retry the same operation at the same endpoint with the same api_call_unique_identifier and unchanged request body. Keep the original request so that optional fields and values remain unchanged. Use delayed, bounded retries; do not start activation or another dependent operation until the previous operation has a confirmed successful result.

If the original status request succeeded, an identical duplicate returns its recorded response without applying the status operation again. That response describes the original operation, not necessarily the card's current state after later changes.

• 1066: the original request is still processing. Wait and retry the unchanged request with the same identifier. Do not use a new identifier to bypass this response.
• 993: the identifier has already been used with different request data. Restore the original body if you are retrying it. For a genuinely different operation, use a new identifier after resolving the original outcome.
• If the recorded operation failed with 987, 988, 989, 1034, or 1066, an identical retry is eligible for reprocessing. Retry with the same identifier and body after a delay; reprocessing does not guarantee success. The processing-pending rule above takes precedence for 1066.
• Other recorded failures are returned again for an identical duplicate. Do not keep retrying them unchanged. Correct invalid input and use a new identifier for the corrected request only when the original outcome is resolved. If the error is unexplained or persists, stop and contact Paymentology support with the identifier.

After confirmed activation success, check the resulting body.status_nwk. If it differs from the desired status because activation applied the stored renewal status, issue action: 1 as a new operation with a new identifier. Replaying the successful activation with its old identifier does not perform this status change.