Card Renewal V2

This web service creates a new card and maintains a reference to the old one when one of the following actions is required :

  1. Replacement (new pan + new token + new expiry generated).
  2. Renew (old pan + old token + new expiry generated)

A reason for the replacement is also required and recorded against the renewal action.

Body Params
string
required
length between 1 and 40

Unique number that must be passed at each API request. Identifier to make each API request unique

int32
required
1 to 2

card action :

  • 1==>Replacement (new pan + new token + new expiry generated)
  • 2==> Renew (old pan + old token + new expiry generated)
int32
required
≥ 1

Unique identifier for the client which Paymentology will provide at outset

int32
required
1 to 4

How to deliver image back to client. Example :

  • 1==> Image in plain base64, encrypted pan, cvv, token, expiry, and emboss_name).
  • 2 ==> Image in byte encrypted, encrypted pan, cvv, token, expiry, and emboss_name.
  • 3 ==> Data details JSON (encrypted pan, cvv, token, expiry, and emboss_name but no image.
  • 4 ==> Image in byte encrypted, masked pan back, cvv, token, expiry, and emboss_name.
string
required
length between 5 and 5

Show or hide pan, cvv, expiry, token, and emboss_name in response image. 1 means show and 0 means hide

PositionField
1pan
2cvv
3expiry
4emboss_name
5token

EG: 00111 (Hide pan and cvv but show expiry, token, and emboss_name).

string
required
length between 0 and 50

Image template name for the card to be generated. This field is case sensitive. card image has to be populated as configured in PayControl.

int64
required
≥ 1

Public token for the card

string
required
length between 5 and 5

Show or hide pan, cvv, expiry, token, and emboss_name in response json. 1 means show and 0 means hide

PositionField
1pan
2cvv
3expiry
4token
5emboss_name

EG: 00111 (Hide pan and cvv but show expiry, token, and emboss_name).

string
length between 0 and 50

User Id of the Customer who triggered the API request.

string
length between 0 and 200

Remarks for API request

string
length between 0 and 255

Reason for renewal or replacment

string
length between 0 and 50

Future field 1RFU

string
length between 0 and 50

Future field 2RFU

int32
string
string
int32

Status network : 
Allowed values for renewal

  • 1000 : Fully operational DE39=00
  • 1001 : Refer to issuer DE39=01
  • 1004 : Capture card DE39=04
  • 1008 : Honour with ID DE39=08

Disallowed values for renewal 
If a card is void i.e status_nwk = 1199 or status_nwk = 1009 then card can not be replaced/renewed.

We set card status_nwk into below values through pws_set_card_status web service and only process for card renewal.

  • 1005 : Decline all txns DE39=05
  • 1006 : Inactive - pin blocked DE39=75
  • 1007 : Decline all txns (Visa: DE39=12) (MC: DE39=14)
  • 1041 : Lost card - capture DE39= 41
  • 1043 : Stolen card - capture DE39=43
  • 1054 : Expired card - report DE39=54
  • 1154 : Expire card - don't inform
  • 1062 : Restricted card
string

Flags for token to assign various tasks to the card. 0 ==>Flag inactive | 1==> Flag Active . Descriptions for each tok flag bits are given below :

TOK_DESCRIPTIONBIT_POSITION
Send card bal in De54 in next auth3
Send pin unblock to card4
Set card to decline all tranasaction except ecommerce5
Set card to decline all Contactless transaction6
Set card to decline all Ecommerce9
Set card to decline all ATM10
Set card to decline Bal enquiry over auth11
Set card to decline cash back txns12
Set card to decline Auth credit pur/refund (DE3_1=20)14
Set card to decline credit payment (DE3_1=28)19
Set card to decline non base currency txn20
Set card to decline all account enq (de61_7=8)21
Set card to decline card not present txns22
Set card to decline Cardholder not present txns23
Set card to decline failover to mag at emv capable atm24
Set card to decline mag at atm25
Alow if fallback chp->mag at chp capable pos DE22_1=8026
Allow if de22_1=02 & De48_88 =Y27
Set card to approve if AVS match fails28
Set card to decline Recurring transaction29
int32

Card product id.

1. If no card product id sent, then default value set at card is taken.

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.

string

Expiry date during renewal/replacement. Accepted format yyyy-mm-dd hh:mm:ss

If client send expiry in request, same is assigned during replacement/renewal.

If expiry date is not send by client, automatic expiry date is computed from product level. This applies to both renewal and replacement.

Note : There could be a scenario where weak cvv is computed during renewal/replacement. Example 111, 222

1. Replacement(new pan, new token, new expiry)

  • 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.

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.

  • If client send expiry in request and weak cvv is computed, then below response will be sent to client.
    weakCvv (1028, Weak cvv computed. Change expiry and resend request again)

  • 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
string

ISO 639-1 two-letter language code.

3ds_challenge_methods
array of objects
3ds_challenge_methods
string

Unique identifier for the challenge profile. 3ds_challenge_methods will be ignored if this value is not null.

int32
1 to 2
  • 1 = Physical card
  • 2 = Virtual card
string
length between 0 and 30

Emboss name.

string
length between 0 and 50

Customer reference

string
length between 0 and 10

delivery Title.

string
length between 0 and 50

delivery First Name.

string
length between 0 and 50

delivery Last Name.

string
length between 0 and 100

Delivery Address 1

string
length between 0 and 100

Delivery Address 2

string
length between 0 and 15

delivery Postal Code.

string
length between 0 and 50

delivery City.

string
length between 0 and 50

delivery Country.

string
length between 0 and 60

delivery Email.

string
length between 0 and 20

delivery Mobile. phone number format i.e 00 (contry code ) phone number or + (country code) phone number.

string

delivery Pass Code.

int32

delivery method for card :

  • 0 – Standard mail
  • 1 – Registered mail
  • 2 – Direct delivery (courier) RFU
int32

delivery account Number.

string
length between 0 and 50

delivery Holder Region.

string
length between 0 and 10

Purchaser Title.

string
length between 0 and 50

Purchaser First Name.

string
length between 0 and 50

Purchaser Last Name.

string
length between 0 and 100

Purchaser Address 1.

string
length between 0 and 100

Purchaser Address 2.

string
length between 0 and 15

Purchaser Postal Code.

string
length between 0 and 50

Purchaser City.

string
length between 0 and 50

Purchaser Country.

string
length between 0 and 60

Purchaser Email.

string
length between 0 and 20

Purchaser Mobile,phone number format i.e 00 (contry code ) phone number or + (country code) phone number.

int32

Purchaser account Number

string
length between 0 and 10

Purchaser pass code (can be stored against card for customer authentication [i.e. activation stage], or Paymentology can generate)

string
length between 0 and 50

Purchaser region.

int32

Purchaser customer type. This will determine the single delivery of a card to specific address

  • 0 => Card will be delivered to card holder address
  • 1 => Card will be delivered to purchaser address
int32

Bulk delivery address code.
It can be any value set by bank themselves. 

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.
So if a card has bulk_delv_add_code = 10505, then this code is used to identify the delivery address inside <BULK_DEL> tag in perso file xml.

 

Example : 
If a client creates a batch of 5 cards and need to deliver to a single address.
Then bank can agree a value for bulk_delv_add_code other than 0 and put same delivery address for all cards. This will deliver cards to single address in bulk inside <BULK_DEL> tag in perso file xml.

 

Note: If client need to send 5 cards to AddressX and 6 cards to AddressY, then client need to set different bulk_delv_add_code for two batch of cards.
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.


If client sets bulk_delv_add_code same for 5 cards but different delivery address for each card, then all cards will be delivered to delivery address of first created card.


If a client creates a card and need to deliver to a specific single address.
Then client can input either card holder address/details or purchaser address/ details based on pur_cust_type field. At this point client can put bulk_delv_add_code = 0 or empty/null so that it determines the card is for single delivery and address/details are populated inside <RECORD>==><CH_ADDR> tag in perso file xml

pur_cust_type

  • 0 => Card will be delivered to card holder address
  • 1 => Card will be delivered to purchaser address
int32

delivery Code, carriers with same del_code, will be grouped to be send to a specified delivery address.

int32

card manufacturer id (If not passed then will take default manuf id will be taken from manufacturer table)

string

Allows client to stipulate carrier type (card packaging type choice - for shipment to customer). Possible

int32
≤ 32767

Identifies insert 1 to be included with Carrier in Envelope

int32
≤ 32767

Identifies insert 2 to be included with Carrier in Envelope

string
length between 0 and 3

Language to be used in carrier notes and labels(iso 3166-1, character three digits).

int32
≤ 32767

Identifies envelope type

string
length between 0 and 20

Extra card text line 1, allows additional line for subjective requirements i.e. extra text in the card

string
length between 0 and 20

Extra card text line 2, allows additional line for subjective requirements i.e. extra text in the card

string
length between 0 and 255

string [ 0 .. 255 ] characters Customer special details, i.e. QR code If custom_1 ==> 1, then we will provide : MMYY+Public Token (MMYY ->the date of card creation ). If custom_1 value other than "1" , PT will include what ever client input in the same field in create.

string
length between 0 and 35

Emboss line 4, front of card additional text i.e. private token

string
length between 0 and 50

Track 3, Mag stripe

string
length between 0 and 60

product identifier, i.e. physical card design reference used by the card printer.

string
length between 0 and 100

Unique client reference relating to order, card or customer where present should always be quoted in correspondence

int32
0 to 1

Inherit existing card rules. Based on value provide, it will either inherit existing rules or skip. 

  • 0 ==> Inherit
  • 1 ==> Donot inherit

Default value is 0 i.e. always inherit

boolean

Transfer digital tokens to new card. Digital token states will not be updated.

Responses

404

Webservices does not exist

500

Internal Server error

Language
LoadingLoading…
Response
Click Try It! to start a request and see the response here! Or choose an example:
application/json