ManageCreditCard

Description

Triggers the process of registering a credit card in external system SIA.
When UNIAPI receives this request:

1. Creates new transaction in GVP_SIA_MICROPAYMENTS (status 0: Pending).
2. Returns SIA data, micropayment data and signature.
   1.  If user has an active token in GVP_USERS_SIA_CARDS: returns SiaRegisterParams with oldtoken and generates signature for modToken SIA request.
   2.  Else, returns SiaRegisterParams without oldtoken and generates signature for authorise SIA request.
3. If user has a pending micropayment, returns error (statusCode = 271, statusMessage = WaitingForPendingMicropayment). User will be able to try again when pending micropayment is resumed.

This method only can be used by logged user.

Parameters

• token (String, required)

A valid token for identifying the API session context and logged user.

• clientUrlOk (String, required)

It is the URL to redirect end user browser at the end of a successful credit card registration/replacement.

It will be used together with clientUrlKo to generate URLOK in this way: Params.URLOK = [BLOCK1]?clientUrlOK=[BLOCK2]&clientUrlKO=[BLOCK3] where:

BLOCK1 is gvp.sia.api endpoint offering CreditCardController Confirm service which processes SIA successful transactions. This endpoint is configured by operator at instance parameter SIA_URL_OK. Example: http://sianotification.mca.tid.es/api/creditcard/confirm

BLOCK2 is URL to redirect end user browser at the end of a successful credit card registration/replacement. This URL is sent by PCClient to gvp.api as input parameter clientUrlOk to manageCreditCard service. Example: http://vivoplay.mca.tid.es/CreditCardOk

BLOCK3 is URL to redirect end user browser at the end of a credit card registration/replacement which seems to be OK at SIA side but fails at GVP (e.g. because signature validation fails). This URL is sent by PCClient to gvp.api as input parameter clientUrlKo to manageCreditCard service. Example: http://vivoplay.mca.tid.es/CreditCardFailed

• clientUrlKo (String, required)

It is the URL to redirect end user browser at the end of a failed credit card registration/replacement.

It will be used to generate URLKO in this way: Params.URLKO = [BLOCK1]?clientUrlKO=[BLOCK2] where:

BLOCK1 is gvp.sia.api endpoint offering CreditCardController Refuse service which processes SIA successful transactions. This endpoint is configured by operator at instance parameter SIA_URL_OK. Example: http://sianotification.mca.tid.es/api/creditcard/refuse

BLOCK2 is URL to redirect end user browser at the end of a failed credit card registration. This URL is sent by PCClient to gvp.api as input parameter clientUrlKo to manageCreditCard service. Example: http://vivoplay.mca.tid.es/CreditCardFailed

Returns

Returns a JSON object containing a SiaRegisterParams object which represents the list of parameters that must be sent to SIA to call registration card form.

Example:
Example for authorise method (it doesn't require the modtoken params).

{

 "formUrl": "http://216.177.213.245:6980/servlet/ServletDirector",
 "Params": {
   "IDVERSION": "0001",
   "IDENTIDAD": "TVID",
   "IDCOMERCIO": "055720353",
   "IDUSUARIO": "12313",
   "IDTM": "1200",
   "OPCTTOKEN": "01",
   "IDPEDIDO": "MIC1231313",
   "IMPTRANS": "50",
   "CODMON": "978",
   "TIMETRANS": "2016-01-13T01:55:11.515 Etc/UTC",
   "IPORIGEN": "195.235.092.025",
   "FIRMTOKEN": "MkdqtXsJHXZ1ZbWM2N8xVwNGvHMTAcuvFEOTYxtjCkL9i9wSkMeoj5tP2TsRNvVi7GMSTZFifIYGRtkgDAXFiQfypIPVL5ExjBD71Dbm6qRKCJaT3wg+ZG3M3x85k0kcg0o8w/4MreKGXC2QJZSs3WpScftMC3wJFEDlnGPXBmS55HWaMlYDE8iF75wFsdDGrZpju2TlsmCCospM4sB2izv2iSYTU6atqjOnW0X1FAwc7lBfzR1BJY4Uiqt20P+5E6vYv04H+BIUcW8OvT1pnYbp1dCo+wRajO4gk9ZuDGfnb8Yhv231EzH9P7aar2V+UUrripFw93jlXTyR9ll+AA==",
   "TOKEN":"", 
   "DESTOKEN": "Default",
   "SUSTKNSUSCRIP":"",
   "BJATKNANT":"",
   "URLOK": "http://sianotification.mca.tid.es/api/creditcard/confirm?clientUrlOK= http://vivoplay.mca.tid.es/CreditCardOk&clientUrlKO=http://vivoplay.mca.tid.es/CreditCardFailed",
   "URLKO": "http://sianotification.mca.tid.es/api/creditcard/refuse?clientUrlKO=http://vivoplay.mca.tid.es/CreditCardFailed",
   "sNombreEvento": "1200",
   "sIdWindow": "Interface"
 }

}

Exceptions

• AuthenticationRequiredException
• WaitingForPendingMicropayment

Caching

This method is not cached.

Known issues

None

Version history

API Version Number	Change description	Changes author
1.0	Initial method design
1.1	New input parameters and new SiaRegisterParams object definition
1.2	updated definition for Params.URLOK and Params.URLKO

See also

SIGNATURE GENERATION FOR MANAGE CREDIT CARD OPERATIONS (authorise and modToken)

The signature generation for any operation must be performed in two steps:

1. To create a char string containing only the values of the fields to be sent in the request for the operation and with the same order. Only fields values must be taken in account, without any separator and without field names. The data to be concatenated must be encoded as a UTF-8 string. Keep in mind that it should have the same character encoding as input to the algorithm for calculating the signature and to validate it.
2. Once the string is created the firm is generated calling the corresponding C# method using the keystore that contains the public key.

For authorise operation: Previous table shows the list of fields to be used to create a string in the generation of the TokenSignature to register the first credit card and AUTHORISE a micropayment in SIA, taking only the rows which has a N in Only for modtoken column and Y in used for RSA calculation. Check that for example, URLOK and URLKO are not used for the signature.

Take into account that table rows ordering must be kept.

Example of a string to be signed: 0001TVID05572035312313120001MIC1231313509782015-12-09T14:19:28.373 Etc/UTC195.235.092.025Default

For modToken operation: As in previous situation, in order to calculate the signature, the table must be taken into account, considering all the rows which has an Y for used for RSA calculation column (so taking all the N/Y rows in Only for modtoken column). Table rows ordering must be kept to concatenate the values and then proceed with the RSA algorithm.