Card Renewal V2

<p>The identifier for this operation. Use a new value for each separate renewal, activation, or status change. To retry the same operation after a timeout or lost response, reuse its identifier and send the same request body to the same endpoint. Do not reuse an identifier with changed request data. See the page's retry instructions for duplicate and failed-request behavior.</p>

<p>card action :</p><ul><li class="docBullet">1==&gt;Replacement (new pan + new token + new expiry generated)</li><li class="docBullet">2==&gt; Renew (old pan + old token + new expiry generated)</li></ul>

<p>How to deliver image back to client. Example :</p><ul><li class="docBullet">1==&gt; Image in plain base64, encrypted pan, cvv, token, expiry, and emboss_name).</li><li class="docBullet">2 ==&gt; Image in byte encrypted, encrypted pan, cvv, token, expiry, and emboss_name.</li><li class="docBullet">3 ==&gt; Data details JSON (encrypted pan, cvv, token, expiry, and emboss_name but no image.</li><li class="docBullet">4 ==&gt; Image in byte encrypted, masked pan back, cvv, token, expiry, and emboss_name.</li></ul>

<p>Show or hide pan, cvv, expiry, token, and emboss_name in response image. 1 means show and 0 means hide</p><ul><li class="docBullet"><code>1</code> — pan</li><li class="docBullet"><code>2</code> — cvv</li><li class="docBullet"><code>3</code> — expiry</li><li class="docBullet"><code>4</code> — emboss_name</li><li class="docBullet"><code>5</code> — token</li></ul><p>EG: 00111 (Hide pan and cvv but show expiry, token, and emboss_name).</p>

<p>Show or hide pan, cvv, expiry, token, and emboss_name in response json. 1 means show and 0 means hide</p><ul><li class="docBullet"><code>1</code> — pan</li><li class="docBullet"><code>2</code> — cvv</li><li class="docBullet"><code>3</code> — expiry</li><li class="docBullet"><code>4</code> — token</li><li class="docBullet"><code>5</code> — emboss_name</li></ul><p>EG: 00111 (Hide pan and cvv but show expiry, token, and emboss_name).</p>

<p>The optional reason for renewal or replacement, up to 255 characters. If omitted, no reason is supplied with the request.</p>

<p>Reserved metadata used to reconstruct a previously completed response. Omit this field from requests; it is not a client control for renewal or replacement. Omitting it does not change the operation.</p>

<p>Reserved metadata used to reconstruct a previously completed response. Omit this field from requests; it is not a client control for renewal or replacement. Omitting it does not change the operation.</p>

<p>Reserved metadata used to reconstruct a previously completed response. Omit this field from requests; it is not a client control for renewal or replacement. Omitting it does not change the operation.</p>

<p>The network status to assign to the card. You do not need to call <code>pws_set_card_status</code> first to apply this value. For a physical-card renewal with <code>card_action=2</code> and an unchanged card product, Lume applies this status immediately to the current card and stores the same status for the pending renewal. You cannot specify separate statuses for the current card and the pending renewal in this request.</p><p>Default: <code>1000</code>. Omitting this field applies <code>1000</code>; it does not preserve the current status. To keep an otherwise usable card operational while the renewal is pending, specify <code>1000</code> or omit this field. Specifying <code>1005</code> blocks the current card and stores <code>1005</code> for the renewal.</p><p>Allowed values:</p><ul><li class="docBullet"><code>1000</code> — Fully operational.</li><li class="docBullet"><code>1001</code> — Refer to issuer.</li><li class="docBullet"><code>1004</code> — Capture card.</li><li class="docBullet"><code>1005</code> — Decline all transactions.</li><li class="docBullet"><code>1007</code> — Decline all transactions.</li><li class="docBullet"><code>1008</code> — Honor with ID.</li><li class="docBullet"><code>1041</code> — Lost card; capture card.</li><li class="docBullet"><code>1043</code> — Stolen card; capture card.</li><li class="docBullet"><code>1054</code> — Expired card; report expiry.</li></ul><p>Values outside this list fail request validation.</p><p>Lume checks the existing card separately. Existing statuses <code>1005</code>, <code>1006</code>, <code>1007</code>, <code>1041</code>, <code>1043</code>, <code>1054</code>, <code>1154</code>, and <code>1062</code> do not by themselves prevent renewal; other renewal checks still apply. You do not need to set one of these statuses before renewal. This list describes existing-card eligibility, not additional allowed values for this request.</p><p>An existing card with status <code>1009</code> or <code>1199</code> is void and cannot be renewed or replaced. Existing statuses <code>1010</code> (due payment block) and <code>1011</code> (KYC/AML hold) also prevent renewal or replacement. The requested <code>status_nwk</code> cannot override these restrictions.</p><p>When you activate the pending renewal with <code>v2_pws_set_card_status</code> and <code>action=2</code>, Lume applies the status stored during renewal instead of the status supplied in that activation request. To change it, make a separate status request with <code>action=1</code> after activation.</p><p>DE39 is the payment network response-code field; the listed values explain the authorization response associated with each status.</p>

<p>The card control flags, encoded as exactly 32 characters containing only <code>0</code> and <code>1</code>. Positions are one-based, counted from left to right: position 1 is the leftmost character. <code>1</code> enables a flag; <code>0</code> disables it. Omit this field to retain the existing card's flags. A supplied value replaces all 32 flags; an all-zero value clears them.</p><p>For example, <code>00001000000000000000000000000000</code> sets only position 5 (decline transactions other than e-commerce). Other card status and authorization checks still apply. To retain other restrictions, preserve their positions in the supplied value.</p><ul><li class="docBullet"><code>3</code> — Send card bal in De54 in next auth</li><li class="docBullet"><code>4</code> — Send pin unblock to card</li><li class="docBullet"><code>5</code> — Set card to decline all tranasaction except ecommerce</li><li class="docBullet"><code>6</code> — Set card to decline all Contactless transaction</li><li class="docBullet"><code>9</code> — Set card to decline all Ecommerce</li><li class="docBullet"><code>10</code> — Set card to decline all ATM</li><li class="docBullet"><code>11</code> — Set card to decline Bal enquiry over auth</li><li class="docBullet"><code>12</code> — Set card to decline cash back txns</li><li class="docBullet"><code>14</code> — Set card to decline Auth credit pur/refund (DE3_1=20)</li><li class="docBullet"><code>19</code> — Set card to decline credit payment (DE3_1=28)</li><li class="docBullet"><code>20</code> — Set card to decline non base currency txn</li><li class="docBullet"><code>21</code> — Set card to decline all account enq (de61_7=8)</li><li class="docBullet"><code>22</code> — Set card to decline card not present txns</li><li class="docBullet"><code>23</code> — Set card to decline Cardholder not present txns</li><li class="docBullet"><code>24</code> — Set card to decline failover to mag at emv capable atm</li><li class="docBullet"><code>25</code> — Set card to decline mag at atm</li><li class="docBullet"><code>26</code> — Alow if fallback chp->mag at chp capable pos DE22_1=80</li><li class="docBullet"><code>27</code> — Allow if de22_1=02 & De48_88 =Y</li><li class="docBullet"><code>28</code> — Set card to approve if AVS match fails</li><li class="docBullet"><code>29</code> — Set card to decline Recurring transaction</li></ul><p>In the list, DE means a payment-message data element: DE54 carries balance information, DE3 identifies the transaction type, DE61 carries point-of-sale information, DE22 identifies the card-entry method, and DE48 carries additional transaction data. ATM means automated teller machine; POS means point of sale; AVS means address verification service. MDES and VTS are Mastercard and Visa digital token services. EMV refers to chip-card payment standards.</p>

<p>Card product id.</p><p>1. If no card product id sent, then default value set at card is taken.</p><p>2. If card product id is sent different from one set during card create, it will act as replacement i.e. new pan, new token since bin range value will be different.</p>

<p>Expiry date during renewal/replacement. Accepted format yyyy-mm-dd hh:mm:ss<br /><br />If client send expiry in request, same is assigned during replacement/renewal.</p><p>If expiry date is not send by client, automatic expiry date is computed from product level. This applies to both renewal and replacement.</p><p>Note : There could be a scenario where weak cvv is computed during renewal/replacement. Example 111, 222</p><p>1. Replacement(new pan, new token, new expiry)</p><ul><li>If weak cvv is computed as per pan selected, system will internally discard this pan and look for new pan such that new cvv is computed.</li></ul><p>2. Renewal (same pan, same token, new expiry). Since pan should not be changed during renewal, so we change expiry such that new cvv is computed.</p><ul><li>If client send expiry in request and weak cvv is computed, then below response will be sent to client.<br /><span style="color: #333399;"><strong>weakCvv (1028, Weak cvv computed. Change expiry and resend request again)</strong></span><br /><br /></li><li>If client do not send expiry in request, then automatic expiry is computed from product level. Now if a weak cvv is computed, then system will internally increase 1 month to automatic computed expiry and process request again</li></ul>

<ul><li class="docBullet">1 = Physical card</li><li class="docBullet">2 = Virtual card</li></ul>

<p>delivery method for card :</p><ul><li class="docBullet">0 &ndash; Standard mail</li><li class="docBullet">1 &ndash; Registered mail</li><li class="docBullet">2 &ndash; Direct delivery (courier) (reserved for future use)</li></ul><p>For same-product renewal, omission retains the existing delivery method.</p>

<p>Purchaser customer type. This will determine the single delivery of a card to specific address</p><ul><li>0 =&gt; Card will be delivered to card holder address</li><li>1 =&gt; Card will be delivered to purchaser address</li></ul>

<p>Bulk delivery address code.<br />It can be any value set by bank themselves.&nbsp;</p><p>Bank can use any value to group the cards that will be delivered to a specific address. This value is the bulk_delv_add_code.<br />So if a card has bulk_delv_add_code = 10505, then this code is used to identify the delivery address inside &lt;BULK_DEL&gt; tag in perso file xml.</p><p>&nbsp;</p><p>Example :&nbsp;<br />If a client creates a batch of 5 cards and need to deliver to a single address.<br />Then bank can agree a value for <em><strong>bulk_delv_add_code</strong></em> other than 0 and put same delivery address for all cards. This will deliver cards to single address in bulk inside &lt;BULK_DEL&gt; tag in perso file xml.</p><p>&nbsp;</p><p>Note: If client need to send 5 cards to <em><strong>AddressX</strong></em> and 6 cards to <em><strong>AddressY</strong></em>, then client need to set different <em><strong>bulk_delv_add_code</strong></em> for two batch of cards.<br />Like for 5 cards set bulk_delv_add_code = X and for 6 cards set bulk_delv_add_code = Y. This will distinguish separate bulk delivery address for different sets of cards.</p><p><br />If client sets <em><strong>bulk_delv_add_code</strong></em> same for 5 cards but different delivery address for each card, then all cards will be delivered to delivery address of first created card.</p><p><br />If a client creates a card and need to deliver to a specific single address.<br />Then client can input either card holder address/details or purchaser address/ details based on <em><strong>pur_cust_type</strong></em> field. At this point client can put <em><strong>bulk_delv_add_code</strong></em> = 0 or empty/null so that it determines the card is for single delivery and address/details are populated inside &lt;RECORD&gt;==&gt;&lt;CH_ADDR&gt; tag in perso file xml</p><p><em><strong>pur_cust_type</strong></em></p><ul><li>0 =&gt; Card will be delivered to card holder address</li><li>1 =&gt; Card will be delivered to purchaser address</li></ul>

<p>The configured card manufacturer ID. If supplied as a positive ID, it must identify a manufacturer configured for your client. For same-product renewal, omit this field to retain the existing manufacturer. Do not send <code>0</code> to request retention.</p>

<p>The card packaging code used by your configured manufacturer. There is no API-wide list of values. Use the code specified by your card fulfillment configuration. For same-product renewal, omit this field to retain the existing code.</p>

<p>Inherit existing card rules. Based on value provide, it will either inherit existing rules or skip.&nbsp;</p><ul><li>0 ==&gt; Inherit</li><li>1 ==&gt; Donot inherit</li></ul><p>Default value is 0 i.e. always inherit</p>