Cards can be issued to an account or can be non-personalized depending on program configuration. Each account can have a single active card. Card can be either virtual or plastic depending on the program. Cards can be used to pay in any physical location, online or withdraw money from ATMs. All virtual cards are activated upon issuing and can be used immediately. All plastic cards are not activated upon issuing and must be activated by the customer once received.
All virtual cards are activated upon issuing and can be used immediately.
All plastic cards are not activated upon issuing and must be activated by the customer once received.
Cards can be converted from virtual to plastic at a later stage. The PIN can be set on card creation or changed at a later stage on ATM.
Apple Pay/Google Pay push provision is supported depending on the program.
Sections
Card Creation
POST/v2/cards
Operationcard_create
Request body
Field
Type
Description
program
string(0,any)
account
string(0,any)
merchant
string(0,any)
Required only for non pesonalized card in case must be assigned to merchant immediately.
user
string(0,any)
Required only for non pesonalized card in case must be assigned to user immediately.
aml
string(0,any)
Token of AML check. Conditinal: depending on program configuration
Card creation can require different fields depending on type (virtual, plastic) and affiliation (customer, non-personalized).
**Virtual Cards** - to create a virtual card associated with a customer account, please include the account identifier and type of card (virtual). In case the name of the merchant/user is not present in the customer profile, please specify them in the emboss name, emboss name line 4, first and last name (for natural persons) fields of the API request.
**Plastic Cards** - the requirements for plastic card issuing for an account associated with a customer are similar to those for virtual cards. The only addition is to include the delivery details of the cardholder.
The program associated with the account will be used when the card is created. Virtual accounts use the balance of the primary (main) account.
**Non-personalized virtual cards** - the required fields are program code and type of the card (virtual).
**Non-personalized plastic cards** - the requirements for non-personalized plastic card issuing are similar to those for non-personalized virtual cards. The only addition is to include the card delivery details.
For all cases above there are additional fields which can be provided like PIN, fulfil and thermal line data. Card 3DS details can also be provided in order for the card to be enrolled immediately after creation.
Please be advised that fulfil and thermal line data usage and placement on the card may vary depending on the personalization bureau. Contact your account manager before usage.
Card Conversion
PUT/v2/cards/{card}/convert
Operationcard_convert
Path parameters
Name
Example
Description
card
stringrequired
e61bac10-5be2-49e6-99e1-82ccfd4cb644
Token from card creation
Response
Field
Type
Description
code
integer(0,any)
Example response
{
"code": 0
}
Virtual cards can be converted to plastic. The requirement for conversion is card delivery details to be present when the virtual card was created or added when making a request to the conversion API endpoint.
Card Activation
PUT/v2/cards/{card}/activate
Operationcard_activate
Path parameters
Name
Example
Description
card
stringrequired
e61bac10-5be2-49e6-99e1-82ccfd4cb644
Token from card creation
Request body
Field
Type
Description
aml
string(0,any)
Conditional: For some cases for non personalized cards.
Example request
{
"aml": "f37377c0-50c0-4324-a330-902f92db23a4"
}
Response
Field
Type
Description
code
integer(0,any)
Example response
{
"code": 0
}
Plastic cards are always created not activated, meaning no transactions can be executed with the card before activation. Activation is a one-time process and must be done once the card is received by the cardholder for security reasons.
By default, cards are created in active status. This means that card transactions can be executed with the card on POS, ATM, E-commerce, etc.
Please be advised, active status is different than card activation. While activation is a one-time process, card statuses can be changed between active/inactive at any time.
Inactive
Inactive status restricts all transactions with the card. The status is reversable to active.
Closed
Void status destroys the card. No transactions can be done.
By default, limit and fee groups are set upon card creation depending on program configuration. Each limit/fee group can be changed or removed at any time.
The group codes will be provided by Paynetics and must be associated with the program, or the change will not be executed.
Card PIN Management
Card PIN can be retrieved using API at any time.
{ GET }
GET/v2/cards/{card}/pin
Operationcard_retrieve_pin
Path parameters
Name
Example
Description
card
stringrequired
e61bac10-5be2-49e6-99e1-82ccfd4cb644
Token from card creation
Response
Field
Type
Description
code
integer(0,any)
data
object
1 nested field▾
Field
Type
Description
pin
string(0,any)
PIN of the card
Example response
{
"code": 0,
"data": {
"pin": "0123"
}
}
{ POST }
POST/v2/cards/{card}/pin/send
Operationcard_send_pin
Path parameters
Name
Example
Description
card
stringrequired
e61bac10-5be2-49e6-99e1-82ccfd4cb644
Token from card creation
Response
Field
Type
Description
code
integer(0,any)
Example response
{
"code": 0
}
It can be sent to the cardholder via SMS depending on the program configuration. The mobile phone number added upon card creation will be used. In case the phone number must be changed please use the cardholder details update API.
{ DELETE }
DELETE/v2/cards/{card}/pin/reset
Operationcard_reset_pin
Path parameters
Name
Example
Description
card
stringrequired
e61bac10-5be2-49e6-99e1-82ccfd4cb644
Token from card creation
Response
Field
Type
Description
code
integer(0,any)
Example response
{
"code": 0
}
Error counter can be reset using API. This is needed in case the cardholder has entered an incorrect PIN/CVV several times on POS, ATM or online.
Card 3DS Enrollment
POST/v2/cards/{card}/3ds
Operationcard_3ds_enrol
Path parameters
Name
Example
Description
card
stringrequired
e61bac10-5be2-49e6-99e1-82ccfd4cb644
Token from card creation
Request body
Field
Type
Description
otp_sms
string(0,any)required
biometric
boolean
Example request
{
"otp_sms": "+3590000000",
"biometric": true
}
Response
Field
Type
Description
code
integer(0,any)
Example response
{
"code": 0
}
Card can be enrolled for 3DS for both OTP SMS authentication and/or biometric authentication. For OTP SMS authentication the mobile phone number of the account holder is required.
Enrolment mobile phone
PUT/v2/cards/{card}/3ds
Operationcard_3ds_update
Path parameters
Name
Example
Description
card
stringrequired
e61bac10-5be2-49e6-99e1-82ccfd4cb644
Token from card creation
Request body
Field
Type
Description
otp_sms
string(0,any)required
Example request
{
"otp_sms": "+3590000000"
}
Response
Field
Type
Description
code
integer(0,any)
Example response
{
"code": 0
}
**\* number can be amended at a later stage.**
Enrolment for both types
DELETE/v2/cards/{card}/3ds
Operationcard_3ds_remove
Path parameters
Name
Example
Description
card
stringrequired
e61bac10-5be2-49e6-99e1-82ccfd4cb644
Token from card creation
Request body
Field
Type
Description
type
string(0,any)
Example request
{
"type": "string"
}
Response
Field
Type
Description
code
integer(0,any)
Example response
{
"code": 0
}
**\* can be disabled at any time but is not recommended.**
Apple/Google wallet push provisioning is supported depending on the program. Push provisioning is used for automatic In-App provisioning for both platforms.
The API request will return an encrypted payload required for the card to be added to Apple/Google Wallet using the platform SDK/API.