Introduction
PC Server answer structure
{
"answer_type": "[answer_type - request depends]",
"answer": {
"result": {
"error_message": "[error_message]",
"error_code": [error_code]
},
"[answer_type - response object]": {
"[response object field 1]":"[content]",
"[response object field N]":"[content]"
}
},
"answer_version": [answer version - for PC version 6.0 this value is 3]
}
There is API Reference for PC Server
For better understand, how to use this API, we recommend to read further documents:
- Architecture and functionality presentation
- Architecture and functionality
PC API is REST-API. E.g. it uses HTTP request with methods GET, POST, PATCH, DELETE to make any actions.
PC uses Content-Type:application/json with methods POST, PATCH, DELETE. This header must be set in requests.
PC returns request result as JSON object with structure in code area.
Systems endpoint
PC can work with set of Applications simultaneously and separately.
Applications are divided by PC's System identifiers.
Each System can use own billing system, settings, url's and so on.
Usually, Systems endpoint is not used by Applications. It used during installation and configuration.
Register System
endpoint: {{pc-server-api}}/
method: POST
{
"request":"PD94bWwgdmVy..."
}
This request is used to register system identifier (system_id) for Application.
Users, Transactions, Events and so on will be linked to this system_id during Application communication with PC.
request parameter is generated by PC seller.
Get System Details
endpoint: {{pc-server-api}}/{{system_id}}
method: GET
This request will show detailed information about settings of PC's system by system_id.
Change System Settings
endpoint: {{pc-server-api}}/{{system_id}}
method: PATCH
{
"user_keys_expiration_period": 365,
"pc_is_external_url":"https://pc.online-bank.com/pc-client-api/",
"pc_is_internal_url":"http://pc.online-bank.local:8080/pc-pusher-api/",
"events_post_url":"http://anti-fraud-system.local/events/",
"callback_url":"https://abs.net.local/pc-callback/",
"report_template_path":"/opt/wildfly/report.docx",
"license":"{\"request\":{\"systemId\":\"{{system-id}}\",\"dateTime\":1767214799000,\"usersCount\":100000},\"signature\":\"MEUCICthaj2...\"}"
}
This request can be used to change PC's system settings.
All of the parameters are optional.
| Parameter | Description |
|---|---|
| user_keys_expiration_period | Users' keys validity period (in days). After this period user's keys must be updated |
| pc_is_external_url | URL to communicate with PC for mobile app (see Infrastructure scheme) |
| pc_is_internal_url | PC Pusher URL (see Infrastructure scheme) |
| events_post_url | URL to post events about activity in PC (all of the requests), including events and collected data from mobile devices |
| callback_url | default callback url. Used to send callbacks about transactions and users processing (see chapters about users and transactions) |
| report_template_path | path to report template |
| license | license content |
license parameter is generated by PC seller.
Users endpoint
Callback sample for Change User's settings
{
"pc_callback": {
"type": "user_callback",
"result": {
"error_message": "Success",
"error_code": 0
},
"version": 3,
"user_callback": {
"user_id": "stageapi7postpay-3c1a2a05-5a52-4835-b7f6-4d07a81e2a2f",
"updated_settings": {
"device_fingerprint": "0dffffa8ea589f717f2f0f1033adf4053a179c73a682d9f82edc81f98bbaa1bf",
"push_address": {
"device_push_id": "cQGjYE6vQ5SHct1en4h9lF:APA91bF6flaY26c1XPZri8vPNhc2qsr6ihk5AAAAAAAAAAAAAAAAkDZssVhIohgV8W6FkS8j4_g941E-6N_F5VRWBbhxOF660WJK04KqwAa7GE0revXXXXXXXXXXXXXXXX-08R4Y",
"device_type": "Android",
"app_id": "org.paycontrol.app"
}
}
},
"event": {
"event_id": 69306,
"user_id": "stageapi7postpay-3c1a2a05-5a52-4835-b7f6-4d07a81e2a2f",
"session_id": "4c04490d-ee80-47b8-b59a-9c9e062bfbed",
"device_event_id": "7e4887a5-4b3c-4e7e-b80a-e656ba7986f2",
"device_time": 1710339880678,
"request_hash": "c233a90be90f6da19b92864a71ac2e6169851234c30d07bf932ba7f06f26b02c",
"request_hmac": "755219a2c63daf96a01845d0b5b4c842d5cff13acf5d8797cccf121ac91b8b67",
"request_type": "change_user",
"device_info": {
"app": {
"appName": "PayControl",
"packageName": "org.paycontrol.app",
"appVersionName": "6.0.383",
"appVersionCode": 383
},
"wifi": {
"localIp": "192.168.7.10",
"userAgent": "Mozilla\/5.0 (Linux; Android 12; SM-G970F Build\/SP1A.210812.016; wv) AppleWebKit\/537.36 (KHTML, like Gecko) Version\/4.0 Chrome\/122.0.6261.105 Mobile Safari\/537.36__Dalvik\/2.1.0 (Linux; U; Android 12; SM-G970F Build\/SP1A.210812.016)",
"SSID": "wifi-ssid"
},
"memory": {
"totalInternalMemorySize": "118053482496",
"totalRAM": "5542296"
},
"location": {
"latitude": "55.8700000",
"accuracy": "100.00",
"longitude": "37.6800000"
},
"osName": "Android",
"device": {
"product": "beyond0lteser",
"screenWidth": 1080,
"simulator": 0,
"screenHeight": 2119,
"timeZone": "Europe\/Moscow",
"locale": "en",
"manufacturer": "samsung",
"osVersion": "12",
"root": 0,
"name": "SGS10e",
"model": "SM-G970F",
"sdkVersion": 31,
"screenDensity": "3.0"
},
"Android": {
"memory": {
"totalExternalMemorySize": "118053482496",
"hasExternalSDCard": 1
},
"sim": {
"networkCountryIso": "ru",
"phoneType": "GSM",
"simCount": 2,
"simCountryIso": "ru",
"roaming": 0,
"simOperatorName": "Beeline",
"mmsUrl": "http:\/\/wap.samsungmobile.com\/uaprof\/SAMSUNGUAPROF.xml",
"mmsAgent": "SAMSUNG-ANDROID-MMS\/SM-G970F",
"networkOperatorName": "beeline"
},
"sensor": {
"minDelay": 5000,
"vendor": "STM",
"name": "LSM6DSO Acceleration Sensor",
"maxRange": 78.45320129394531,
"type": 1,
"version": 15932,
"resolution": 0.002394201699644327
},
"device": {
"scaledDensity": 3.3000001907348633,
"buildBrand": "samsung",
"buildTime": 1677717204000,
"buildUser": "dpi",
"radioVersion": "G970FXXSGHWB3,G970FXXSGHWB3",
"cpu": "BogoMIPS=52.00;CPU implementer=0x53;CPU architecture=8;CPU variant=0x1;CPU revision=0;Features=fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm dcpop asimddp;processor=7;CPU part=0x003",
"buildID": "SP1A.210812.016",
"defaultSms": "com.samsung.android.messaging",
"deviceID": "a40eff960948fb41",
"buildHost": "21DKG923",
"densityDpi": "480",
"buildVersionCodeName": "REL",
"defaultBrowser": "com.android.chrome",
"certificates": [],
"bootloader": "G970FXXSGHWC1",
"displayVersion": "SP1A.210812.016.G970FXXSGHWC1",
"fingerprint": "samsung\/beyond0lteser\/beyond0:12\/SP1A.210812.016\/G970FXXSGHWC1:user\/release-keys",
"sysAvailableFeatures": "lcZ7yCt+ea7Ot310SW99aq\/GI7U3jwYHP1d4F6Uc1i4=",
"sysSharedLibraryNames": "9CAXPbjcF9Xo5k4CqNbgnTrYIGS5L4JBrum2JMuO05U=",
"device": "beyond0",
"board": "exynos9820",
"hardware": "exynos9820",
"releaseBuildVersion": "12"
}
}
},
"requester_ip_address": "212.46.101.32, 192.168.1.52,172.17.1.3",
"request_result": 0,
"event_data": "{\"current\":{\"device_fingerprint\":\"0dffffa8ea589f717f2f0f1033adf4053a179c73a682d9f82edc81f98bbaa1bf\",\"push_address\":{\"device_push_id\":\"cQGjYE6vQ5SHct1en4h9lF:APA91bF6flaY26c1XPZri8vPNhc2qsr6ihk5AAAAAAAAAAAAAAAAkDZssVhIohgV8W6FkS8j4_g941E-6N_F5VRWBbhxOF660WJK04KqwAa7GE0revXXXXXXXXXXXXXXXX-08R4Y\",\"device_type\":\"Android\",\"app_id\":\"org.paycontrol.app\"}},\"previous\":{\"device_fingerprint\":\"0dffffa8ea589f717f2f0f1033adf4053a179c73a682d9f82edc81f98bbaa1bf\"}}",
"created_at": 1710339881063,
"updated_at": 1710339881085,
"request_url": "http:\/\/pcs:8080\/pc-api\/ext\/1890f265-5c5e-4c28-8601-452a2a488f3c\/users\/stageapi7postpay-3c1a2a05-5a52-4835-b7f6-4d07a81e2a2f",
"pc_instance_name": "pcs-node-1",
"pc_version": {
"pc_version": "6.0.124",
"product": "PC Server",
"pc_api_version": 7
},
"system_id": "1890f265-5c5e-4c28-8601-452a2a488f3c",
"connection_info": {
"dst": {
"port": "8080",
"ip": "172.17.1.7",
"mac": ""
},
"src": {
"port": "52104",
"ip": "172.17.1.2",
"mac": "02-42-AC-11-01-07"
}
},
"key_index": 1,
"device_fingerprint": "0dffffa8ea589f717f2f0f1033adf4053a179c73a682d9f82edc81f98bbaa1bf"
}
}
}
Callback sample for Renew - get challenge
{
"pc_callback": {
"type": "user_callback",
"result": {
"error_message": "Success",
"error_code": 0
},
"version": 3,
"user_callback": {
"user_id": "test-2db1f61a-8824-4411-8ee4-d32da66ec593",
"renew": {
"challenge_request": true
}
}
}
}
Callback sample for Renew - set response
{
"pc_callback": {
"type": "user_callback",
"result": {
"error_message": "Success",
"error_code": 0
},
"version": 3,
"user_callback": {
"user_id": "test-2db1f61a-8824-4411-8ee4-d32da66ec593",
"renew": {
"challenge_response": {
"salt": "63479AD69A090B258277EC8FBA6F99419A2FFB248981510657C944CCD1148E97",
"signature": "3046022100f9a5ceb6c3c2309d2e9ba4a96f7623f7ff9464ac8f07d97de9299d046511f3d1022100b684e226067ab9454949196cf21b134eacfdbfabf2a32b65e28afcc3b6cea66f",
"hmac": "36f310b877092b48e9bf2a192dfaa1517a0c52c907343a233ce26ee91fc26fcd"
}
}
}
}
}
This endpoint is used to manage PC Users.
Application can make following operations with Users
- Create User (generate new key set with unique identifier)
- Update User (mark active key set as "deleted" and generate the new one for existence identifier)
- Change User's settings (usually this method is used by PC mobile app or SDK)
- Export User's keys to transfer them in encrypted state directly to mobile app
- Delete user (mark all data regarding to the User as "deleted")
- Get User details
Some of Users endpoint's methods generate a callback to an url, stored in system settings (see Change System Settings request ). If callback url not set in system settings, no callbacks will be called.
PC calls a callback to inform the Application about changes, made by mobile app.
Methods which generate a callback:
| Method | Callback purpose |
|---|---|
| Change User's settings | Inform the Application about changes in User settings (for example, to determine, if user successfully personalized mobile app - public key and push id values will be updated). |
| Renew User - get challenge | This is internal request to renew user's keys from mobile app side (see Architecture and Principles docs). This method starts keys renew process. |
| Renew User - set response | The same as previous. This method finishes keys renew process. If callback with error_code = 0 was received for this method, then keys were renews successfully. |
To receive callback the Application should realize HTTP(s) POST endpoint. PC will send POST-request with JSON-object. Callback from PC always will contain pc_callback object with following params
| Parameter | Description |
|---|---|
| type | For Users endpoint always will be user_callback |
| result | Result object with description of transaction processing result |
| version | Callback version. Current version is 3 |
| user_callback | Callback data |
result object will contain following params
| Parameter | Description |
|---|---|
| error_code | Error code. 0 means no error |
| error_message | Error description |
user_callback object will contain details of transaction processing. This object will contain one of following objects: updated_settings, renew. It depends on cause of callback was generated.
| Parameter | Description |
|---|---|
| user_id | Identifier of a user which generated callback |
| updated_settings | Repeats content of Change User request (see Change User's Setting ) |
| renew.challenge_request | This value (true) set if mobile app requested key updating |
| renew.challenge_response | This value (object) set if mobile app generated response to renew challenge from PC Server. This object will contain salt, signature and hmac values. error_code = 0 in this callback means that mobile app renewed keys successfully. |
| event | If PC collects events, then this object will contain PC event content. It depends on PC configuration (which data is collecting). |
Create User
endpoint: {{pc-server-api}}/{{system_id}}/users
method: POST
{
"id_prefix":"rest-api-test-",
"user_name":"Acme Ltd.",
"key_params":{
"with_finger_print": true,
"collect_events": false,
"collect_device_info": false,
"collect_device_SIM_info": false,
"collect_device_location": false,
"pass_policy": 0,
"nfc_policy": 1,
"deny_store_with_OS_protection": false,
"deny_renew_public_key": true,
"scoring_enabled": true,
"autosign_enabled": true,
"remote_update_enabled": true,
"server_signer": false
},
"type": 0,
"return_key_method":"FULL_QR"
}
Create User request creates a new user record in PC. This request also generates a new user's identifier, which is unique in PC installation.
This identifier should be stored by Application with real user information.
In case the Application will need a confirmation by user, it should provide PC user's identifier to pick concrete user.
This request generates the data to personalize person's mobile app (PC's client part). This data contain sensitive information (initialization keys) and can be provided to a person in 5 ways:
- via QR-code using offline transfer methods, e.g. printed on a paper and provided into person's hands
- via QR-code with activation code. QR-code can be shown to user online with browser or sent somehow, and activation code MUST be send to user with another communication channel - SMS, IVR, email e.t.c.
- via JSON object in encrypted state to be transferred to person's mobile app via authorized channel with password. Password must be some secret, known by Application and person's mobile app
- via Deep Link for mobile app without activation code. Deep Link can be sent to a user via email or another channel
- via Deep Link with activation code. Deep Link can be sent to a user via email or another channel; activation code by another channel, for example, by SMS
See "Basic uses cases" for more information
How a result will be returned by PC (QR, QR with Activation Code, JSON) will be depend from a request.
return_key_method field specifies this with following values:
FULL_QR- QR-Code for OfflineQR_WITH_ACTIVATION_CODE- QR-Code with Activation CodeKEY_JSON- JSON ObjectDEEP_LINK- Deep LinkDEEP_LINK_WITH_ACTIVATION_CODE- Deep Link with Activation Code
Request Params:
| Parameter | Default | Mandatory | Description |
|---|---|---|---|
| id_prefix | no | Prefix for user's identifier | |
| user_name | no | Suggested user name to show on mobile device (can be changed by end-user on mobile device) | |
| key_params | null | no | Params for User's key |
| type | 0, configurable | no | Crypto type for a user's keyset. 0 - ECSDA + SHA-256 1 - GOST 34.10-2012 + GOST 34.11-2012 |
| return_key_method | YES | Result return method: FULL_QR, QR_WITH_ACTIVATION_CODE, KEY_JSON, DEEP_LINK, DEEP_LINK_WITH_ACTIVATION_CODE |
|
| activation_code_length | 8 | depends | Length of Activation code will be generated to activate QR-code or Deep Link in mobile app. MUST be set if return_key_method is QR_WITH_ACTIVATION_CODE or DEEP_LINK_WITH_ACTIVATION_CODE |
| key_encryption_password | depends | Password to encrypt key values during export. Min length is 6. MUST be set if return_key_method is KEY_JSON |
|
| signer_url | null | no | Specifies url of PC Server Signer for created user, for examplehttp://pc-server-signer-2.loc:8080/pc-server-signer-api/personalize_async |
| app_extra | null | no | Purpose of this parameter is to deliver to a mobile app extra data during personalization process. This data will be returned via PC Mobile SDK after call PCUsersManager.register() method. For example, this data can be used to provide a deep-link to be called by mobile app after personalization. Deep-link can open another app or web-browser to continue a customer journey. Format of this data is unspecified and should be negotiated with mobile app. This value can contain following variables, which will be set by PC Server: %SYSTEM_ID%, %USER_ID%Example of app-extra: "{\"app_callback_deeplink\":\"https://abs.absnet.local/mobile_app_perso_results/%SYSTEM_ID%/%USER_ID%/\"}" |
| url_template | null | depends | If this parameter is set, then QR-code will contain deep-link, created by the template. It can be useful if you process deep-links or universal links in your mobile app. In this case generated QR-code can be scanned with mobile phone's camera app, which will call deep-link handler in your app. This parameter is mandatory if you use DEEP_LINK or DEEP_LINK_WITH_ACTIVATION_CODE return method. PC Server will replace following params in template provided: %SYSTEM_ID%, %USER_ID%, %KEY_URLENCODED%, %KEY_BASE64% Example: paycontrol://user_key?key_json=%KEY_URLENCODED% |
key_params Object:
key_params encodes parameters for User's key. Each field is optional and, in default case, has value false/0.
| Parameter | Description |
|---|---|
| with_finger_print | Link User's key to Mobile Device "fingerprint" after personalization |
| collect_events | Should mobile app send events to the PC Server |
| collect_device_info | ... collect and send device info |
| collect_device_SIM_info | ... collect and send SIM info (requires additional permissions for mobile app) |
| collect_device_location | ... collect and send device location (requires additional permissions for mobile app) |
| pass_policy | Specifies password policy to store keys in mobile app |
| nfc_policy | Specifies NFC-module usage policy to operate with private keys on mobile app |
| deny_store_with_OS_protection | Deny store keys with mobile OS protection methods: TouchID, FaceID, Google Imprint |
| deny_renew_public_key | Deny renew User's public key, e.g. regenerate asymmetric key pair |
| scoring_enabled | Enable mobile device scoring for the user |
| autosign_enabled | Enable autosign feature for the user |
| remote_update_enabled | Enable remote-update feature with extended authentication. This flag is used to create backup data on mobile device to be able to renew a key from backup |
| server_signer | Pick if the user record should be used as server signer (automatically sign transactions on server side without mobile app), see Server Signer User If you use this flag, then — with_finger_print flag MUST be set to false; — online_credentials flag MUST be set to false.In other way PC Server Signer will not able to work. |
| online_credentials | If this flag is true, then activation_code or key_encryption_password will be verified by PC Server. PC Server will count unsuccess activation attempts and will block a PC User if attempts count will be exceeded.PC Mobile SDK will use PC Server online verification feature to set and verify password on mobile device as well with attempts counting. See description of this feature in Architecture and Principles document. |
pass_policy values
| Value | Description |
|---|---|
| 0 | Person can store keys without any protection. If the person uses password - min length is 6 |
| 1 | Person MUST specify password to store keys (or use TouchID, FaceID, Google Imprint). Min length is 6. |
| 2 | Person MUST specify password to store keys (or use TouchID, FaceID, Google Imprint). Min length is 8, up case and down case must be used |
| 3 | Person MUST specify password to store keys (or use TouchID, FaceID, Google Imprint). Min length is 8, up case, down case and digits must be used. |
nfc_policy values
| Value | Description |
|---|---|
| 0 | Usage of NFC-module on mobile app to operate with private key is prohibited |
| 1 | Usage of NFC-module on mobile app to operate with private key is optional |
| 2 | Usage of NFC-module on mobile app to operate with private key is required |
[QR] QR-Code for Offline
[QR] QR-Code for Offline Request sample
{
"id_prefix":"rest-api-test-",
"user_name":"Acme Ltd.",
"key_params":{
"with_finger_print": true,
"collect_events": false,
"collect_device_info": false,
"collect_device_SIM_info": false,
"collect_device_location": false,
"pass_policy": 0,
"deny_store_with_OS_protection": false,
"deny_renew_public_key": false,
"scoring_enabled": false,
"autosign_enabled": false,
"remote_update_enabled": false,
"server_signer": false
},
"return_key_method":"FULL_QR"
}
[QR] QR-Code for Offline Response sample
{
"answer_type": "user_created",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"user_created": {
"system_settings": {
"confirm_code_time_sampling_interval": 180,
"auth_code_time_sampling_interval": 180
},
"user_id": "rest-api-test-1463d9cf-2bad-4ba2-af8c-d66a1632e75c",
"system_id": "70b5fab6-d3d1-4098-aaf9-450a496855f5",
"system_name": "PC Server Develop",
"expiration_timestamp": 1733149357,
"expiration_date": "2024-12-02",
"user_name":"Acme Ltd.",
"key_flags": 1,
"ext_auth_available_methods": [
"codeword",
"oz_biometry"
],
"key_QR": "R0lGODlhLAEsAfAAAAAA... [truncated]"
}
},
"answer_version": 3
}
Application should proceed following actions:
- check if
answer->result->error_codeis0 - get and store
answer->user_created->user_idvalue - print or provide "into hands"
answer->user_created->key_QRvalue
key_QR is base64-encoded GIF-image
Other information in the response is not neccessary to be processed
[QR with Activation Code] QR-Code for Online
[QR with Activation Code] QR-Code for Online Request sample
{
"id_prefix":"rest-api-test-",
"user_name":"Acme Ltd.",
"key_params":{
"with_finger_print": false,
"collect_events": false,
"collect_device_info": false,
"collect_device_SIM_info": false,
"collect_device_location": false,
"pass_policy": 0,
"deny_store_with_OS_protection": false,
"deny_renew_public_key": false,
"scoring_enabled": false,
"autosign_enabled": false,
"remote_update_enabled": false,
"server_signer": false
},
"activation_code_length": 10,
"return_key_method":"QR_WITH_ACTIVATION_CODE"
}
[QR with Activation Code] QR-Code for Online Response sample
{
"answer_type": "user_created",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"user_created": {
"system_settings": {
"confirm_code_time_sampling_interval": 180,
"auth_code_time_sampling_interval": 180
},
"activation_code": "7551332084",
"user_id": "rest-api-test-c0f1cb6a-a34c-4f3b-8b1a-a2e3186effa1",
"system_id": "70b5fab6-d3d1-4098-aaf9-450a496855f5",
"system_name": "PC Server Develop",
"expiration_timestamp": 1733149357,
"expiration_date": "2024-12-02",
"user_name":"Acme Ltd.",
"key_flags": 0,
"ext_auth_available_methods": [
"codeword",
"oz_biometry"
],
"key_QR": "R0lGODlhLAEs... [truncated]"
}
},
"answer_version": 3
}
Application MUST provide activation_code_length value in a request.
Application should proceed following actions:
- check if
answer->result->error_codeis0 - get and store
answer->user_created->user_idvalue - provide with "self service" interface (online-banking, infomat, etc.)
answer->user_created->key_QRvalue - send via the second channel
answer->user_created->activation_codevalue
key_QR is base64-encoded GIF-image
Other information in the response is not necessary to be processed
[JSON] Export key
[JSON] Request sample
{
"id_prefix":"rest-api-test-",
"key_params":{
"with_finger_print": false,
"collect_events": false,
"collect_device_info": false,
"collect_device_SIM_info": false,
"collect_device_location": false,
"pass_policy": 0,
"deny_store_with_OS_protection": false,
"deny_renew_public_key": false,
"remote_update_enabled": false,
"server_signer": false
},
"key_encryption_password":"123456",
"return_key_method":"KEY_JSON"
}
[JSON] Response sample
{
"answer_type": "user_created",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"user_created": {
"expiration_date": "2024-12-02",
"key_json": "{ [key-json] }",
"system_settings": {
"confirm_code_time_sampling_interval": 180,
"auth_code_time_sampling_interval": 180
},
"user_id": "rest-api-test-9bee2f4d-4683-439a-ac40-e06caf3fe8e8",
"system_id": "70b5fab6-d3d1-4098-aaf9-450a496855f5",
"system_name": "PC Server Develop",
"expiration_timestamp": 1733149357,
"user_name":"Acme Ltd.",
"key_flags": 0,
"ext_auth_available_methods": [
"codeword",
"oz_biometry"
]
}
},
"answer_version": 3
}
Application MUST provide key_encryption_password value in a request.
Application should proceed following actions:
- check if
answer->result->error_codeis0 - get and store
answer->user_created->user_idvalue - provide with authorized channel
answer->user_created->key_jsonvalue to person's mobile app
Other information in the response is not necessary to be processed
[Deep Link] To be sent or shown online
[Deep Link] Request Sample
{
"id_prefix":"rest-api-test-",
"user_name" : "User Name",
"key_params":{
"with_finger_print": false,
"collect_events": false,
"collect_device_info": false,
"collect_device_SIM_info": false,
"collect_device_location": false,
"pass_policy": 0,
"deny_store_with_OS_protection": false,
"deny_renew_public_key": false,
"scoring_enabled": true,
"autosign_enabled": true,
"remote_update_enabled": true
},
"return_key_method":"DEEP_LINK",
"url_template": "paycontrol://user_key?key_json=%KEY_URLENCODED%"
}
[Deep Link] Response Sample
{
"answer_type": "user_created",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"user_created": {
"system_settings": {
"confirm_code_time_sampling_interval": 180,
"auth_code_time_sampling_interval": 180
},
"user_id": "rest-api-test-7c4e1033-3e4e-4062-b534-2feec6ea6cec",
"system_id": "0c7c6703-bc60-459d-a01b-c7853ca7e918",
"expiration_timestamp": 1733149357,
"system_name": "PC Server Develop",
"key_flags": 2048,
"key_deep_link": "paycontrol://user_key?key_json=[key-json-url-encoded]",
"ext_auth_available_methods": [
"codeword"
],
"expiration_date": "2024-12-02"
}
},
"answer_version": 3
}
Application should proceed following actions:
- check if
answer->result->error_codeis0 - get and store
answer->user_created->user_idvalue - send to a user
answer->user_created->key_deep_linkvalue
key_deep_link is url for deep link for mobile app.
Other information in the response is not neccessary to be processed.
Be noticed that PC mobile applications (PayControl and PayConfirm) processes deep-links schemes paycontrol and payconfirm respectively.
[Deep Link with Activation Code] To be sent or shown online
[Deep Link with Activation Code] Request Sample
{
"id_prefix":"rest-api-test-",
"user_name" : "User Name",
"key_params":{
"with_finger_print": false,
"collect_events": false,
"collect_device_info": false,
"collect_device_SIM_info": false,
"collect_device_location": false,
"pass_policy": 0,
"deny_store_with_OS_protection": false,
"deny_renew_public_key": false,
"scoring_enabled": true,
"autosign_enabled": true,
"remote_update_enabled": true
},
"return_key_method":"DEEP_LINK_WITH_ACTIVATION_CODE",
"activation_code_length": 10,
"url_template": "paycontrol://user_key?key_json=%KEY_URLENCODED%"
}
[Deep Link with Activation Code] Response Sample
{
"answer_type": "user_created",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"user_created": {
"system_settings": {
"confirm_code_time_sampling_interval": 180,
"auth_code_time_sampling_interval": 180
},
"activation_code": "5002304285",
"user_id": "rest-api-test-1e9db198-bf7f-4cb9-b4d5-bf935e0cd8ab",
"system_id": "0c7c6703-bc60-459d-a01b-c7853ca7e918",
"expiration_timestamp": 1733149357,
"system_name": "PC Server Develop",
"key_flags": 2048,
"key_deep_link": "paycontrol://user_key?key_json=[key-json-url-encoded]",
"ext_auth_available_methods": [
"codeword"
],
"expiration_date": "2024-12-02"
}
},
"answer_version": 3
}
Application MUST provide activation_code_length value in a request.
Application should proceed following actions:
- check if
answer->result->error_codeis0 - get and store
answer->user_created->user_idvalue - send to a user
answer->user_created->key_deep_linkvalue - send via the second channel
answer->user_created->activation_codevalue
key_deep_link is url for deep link for mobile app.
Other information in the response is not neccessary to be processed.
Update User
Request sample
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/key
method: POST
{
"is_delayed":false,
"key_params":{
"with_finger_print": false,
"collect_events": false,
"collect_device_info": false,
"collect_device_SIM_info": false,
"collect_device_location": false,
"pass_policy": 0,
"deny_store_with_OS_protection": false,
"deny_renew_public_key": false,
"scoring_enabled": false,
"autosign_enabled": false,
"remote_update_enabled": true,
"server_signer": false
},
"return_key_method":"FULL_QR"
}
Response sample
{
"answer_type": "key_updated",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"key_updated": {
"expiration_date": "2024-12-02"
"system_settings": {
"confirm_code_time_sampling_interval": 180,
"auth_code_time_sampling_interval": 180
},
"user_id": "rest-api-test-4d02bd9e-ac11-4661-86c5-c7c7965e6a4c",
"system_id": "70b5fab6-d3d1-4098-aaf9-450a496855f5",
"system_name": "PC Server Develop",
"expiration_timestamp": 1733149357,
"key_flags": 0,
"user_name":"Acme Ltd.",
"ext_auth_available_methods": [
"codeword",
"oz_biometry"
],
"key_QR": "R0lGODlhLAEsA... [truncated]"
}
},
"answer_version": 3
}
Update User request updates user's keys in PC. It generates new initial keys, flushes all user's options (like device fingerprint, public key, push identifier, flags) and returns new initials keys just like Create User request.
After this request Application should provide new initial keys to person, like described in Create User request section (QR, QR with Activation Code, JSON, Deep Link, Deep Link with Activation Code). Note that successful execution answer_type is key_updated.
Update User request unblocks blocked user. See Change User Settings request.
Update user request can be executed with is_delayed parameter. If this parameter set to true then PC will not flush user's options at request time. It will generate new initial keys, but in delayed state.
This means that new keys will be put in action in following cases:
- at time of first request from mobile app with new keys
- by request from Application (see Change User Settings request)
Request Params:
| Parameter | Default | Mandatory | Description |
|---|---|---|---|
| is_delayed | false | no | Mark new initial keys as delayed |
| key_params | null | no | The same as for Create User |
| type | 0, configurable | no | The same as for Create User |
| return_key_method | YES | The same as for Create User | |
| activation_code_length | 8 | depends | The same as for Create User |
| key_encryption_password | depends | The same as for Create User | |
| app_extra | null | no | The same as for Create User |
| url_template | null | depends | The same as for Create User |
Export User's Keys
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/key/export
method: POST
Request sample
{
"key_encryption_password":"123456"
}
Response sample
{
"answer_type": "export_key",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"export_key": {
"expiration_date": "2024-12-02"
"key_json": "{ [key-json] }",
"system_settings": {
"confirm_code_time_sampling_interval": 180,
"auth_code_time_sampling_interval": 180
},
"user_id": "rest-api-test-4d02bd9e-ac11-4661-86c5-c7c7965e6a4c",
"system_id": "70b5fab6-d3d1-4098-aaf9-450a496855f5",
"system_name": "PC Server Develop",
"expiration_timestamp": 1733149357,
"key_flags": 0,
"user_name":"Acme Ltd.",
"ext_auth_available_methods": [
"codeword",
"oz_biometry"
]
}
},
"answer_version": 3
}
In case an Application needs to provide user's initial keys not at creation/updating time it can request PC to export keys.
Response will return keys in JSON format like Create User / Update User response.
Request Params:
| Parameter | Default | Mandatory | Description |
|---|---|---|---|
| key_encryption_password | YES | Password to encrypt key values during export. Min length is 6. |
Change User's Settings
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}
method: PATCH
Request sample
{
"block":false,
"unblock":false,
"commit_delayed":false,
"device_fingerprint": "f111f3be77c74abeac08c87c9ee27a56ae53bc546d4e15fb9ff9f372a98794bc",
"push_address":{
"device_type":"Android",
"device_push_id":"ftMhW9ApSEU:APA91bG-v-mvr_1y6MXDF91VDxmCkEnyIwkieKuf5zVY__wdUPhIZUbir5j-5UcDjb7x_YPiakLg8Ismdw55QtQxRZEy0-ufjOchPX2zUA_rx3NlCFsxJoOIawjZL2ZgwXV0DEGRz5R7"
},
"public_key":"3059301306072a8648ce3d020106082a8648ce3d030107034200042ef111f3be77c74abeac08c87c9ee27a56ae53bc546d4e15fb9ff9f372a98794bcc7e95c538035fc3bb0d9c1ba0e46ca5fa394425a400793c3888e7c375dda5e"
}
Response has
result_onlyobject
Application can change following user's setting by this request:
- manually commit delayed key (if user was updated by Update User request with
is_delayedparam) - set device fingerprint (usually this option set by mobile SDK)
- set user's public key (usually this option set by mobile SDK)
- set user's device push identifier (usually this option set by mobile SDK)
All request params are optional.
| Parameter | Default | Mandatory | Description |
|---|---|---|---|
| block | false | no | Pick if user must be blocked. After blocking user's record can not be used in any way. |
| unblock | false | no | Unblock blocked user |
| commit_delayed | false | no | Pick if delayed key should be committed |
| device_fingerprint | null | no | Fingerprint of user's device, collected by mobile SDK |
| push_address | null | no | Object with description of device push identifier. Required to send push to the device |
| public_key | null | no | Public key from device key pair. DER-encoded hex-representation of public key bytes |
This method generates a callback - see Users Endpoint
Reset Password
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/key/credentials/reset
method: POST
Request sample
{
"keys_password": "123456"
}
Response has
result_onlyobject
In case you use online_credentials flag (see description of this feature in Architecture and Principles document and Create User -> key_params) you can reset user's password via request to PC Server.
| Parameter | Mandatory | Description |
|---|---|---|
| keys_password | yes | Password to be set to protect user's key on a mobile device |
Be noticed, that after this call, a user will not be able to use old password.
Delete User
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}
method: DELETE
Request does not contain params
Response has
result_onlyobject
This request mark PC user record as "deleted". User record can not be used for regular work with PC.
It can be only used for Conflicts resolving (see Conflicts resolving section).
Get User Details
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}
method: GET
Request does not contain params
Response sample
{
"answer_type": "user_info",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"user_info": {
"public_key": "3059301306072a8648ce3d020106082a8648ce3d030107034200048262a98e85ddaf2a5b63c3d26bbd7cbf65d3db8c99f3da7f7f76431046224cbe740bf2200e0d87d32d9d2bee39247696046d956a64f5c1f0ddd93c1ea93d242c",
"active_key_info": {
"device_fingerprint": "088ec2e6cb6de77c22c0cad79eaf30a7800594fd77ee8ef3b325d836f77b6cb0",
"expiration_timestamp": 1729111541,
"key_flags": 102175,
"key_index": 1,
"type": 0,
"key_params": {
"nfc_policy": 0,
"deny_renew_public_key": true,
"pass_policy": 0,
"with_finger_print": true,
"collect_device_location": true,
"autosign_enabled": true,
"server_signer": false,
"telegram_enabled": true,
"deny_store_with_OS_protection": false,
"remote_update_enabled": true,
"scoring_enabled": true,
"online_credentials": true,
"collect_events": true,
"collect_device_SIM_info": true,
"collect_device_info": true
}
},
"autosign_public_key": "3059301306072a8648ce3d020106082a8648ce3d030107034200047f09c594a89eb26611abf4c281efa0741feef51d231830afc7282ea47f3617ddd4a89803f7704977e238d3de2a9e2fc77f844e9b5587fdb77c1d4f102e56f184",
"blocked": false,
"user_id": "devapi7postpay-79fceafe-20b9-4203-b711-2844970d61d6",
"user_name":"Acme Ltd.",
"system_id": "70b5fab6-d3d1-4098-aaf9-450a496855f5",
"system_name": "PC Server Develop",
"device_push_id": "eY36FryPRTqsFszOoJeoTs:APA91bG94WbrR5XFViPCqNVOnWDIs6CA72glhV2bjrAQ7IiND6KK7oRTM8p9Si3er-BXI3iKrj9c3ZhztOIwwnmvZlEo5PsLdh3k_EpnIzFSrMHIh2FgR5vV-9bOCKwiveHM4tt1oCxh",
"delayed_key_info": {
"expiration_timestamp": 1734601717,
"key_flags": 34304,
"key_index": 2,
"app_extra": "{\"your_param_name\":\"your_value\"}",
"type": 0,
"key_params": {
"nfc_policy": 0,
"deny_renew_public_key": false,
"pass_policy": 0,
"with_finger_print": false,
"collect_device_location": false,
"autosign_enabled": true,
"server_signer": false,
"telegram_enabled": true,
"deny_store_with_OS_protection": false,
"remote_update_enabled": false,
"scoring_enabled": true,
"online_credentials": false,
"collect_events": false,
"collect_device_SIM_info": false,
"collect_device_info": false
}
},
"device_type": "Android",
"app_id": "org.paycontrol.app"
}
},
"answer_version": 3
}
This request returns information about actual keys and options for PC user.
Response
| Parameter | Mandatory | Description |
|---|---|---|
| active_key_info | YES | Information about active key and options for the user |
| delayed_key_info | NO | Information about delayed key and options (if user was updated with Update User request and is_delayed param) |
| user_id | YES | User identifier in PC |
| system_id | YES | Application identifier |
| system_name | YES | Application name |
| device_type | NO | Registered device type for push notifications. The value options are listed below |
| device_push_id | NO | Registered device push identifier for push notifications |
| public_key | NO | Registered public key. DER-encoded hex-representation of public key bytes |
| blocked | YES | Is user blocked |
Device types
| Value | Push sending method |
|---|---|
| Android | Firebase |
| iOS | APNS |
| Huawei | HMS |
| ServerSigner | There is will no push sends. It will call SeverSigner for sign transaction created for ServerSigner user |
| Telegram | Telegram bot |
| Edna | Edna platform |
Transactions endpoint
Callback sample for confirmation
{
"pc_callback": {
"type": "transaction_callback",
"result": {
"error_message": "Success",
"error_code": 0
},
"version": 3,
"transaction_callback": {
"transaction_id": "f84f2749-75dd-48f9-a0e9-9aaaf99cfa9d",
"check_time": 1576678302,
"confirmation": {
"confirm_code": "99edc1a4608ba2cab4129e51536ef64e73cd2331bd8c2e5be02601bf83c03b27",
"signature": "3045022100cab15bbb76703230ea1c7f931bd2b131240b4262b85df6b44bb6c7fd10e61593022063403a4dce33e139f2cf75bd424f07933ad7e796721aa45ce02d02f9a56a581a",
"gost_imit": "84f6870808f423efa533ced9098ecd6b541622eb26ea398d2b39e48825907f94",
"scoring": {
"gib_sb": {
"score": 0,
"scoreLevel": "NO_RISK"
}
}
}
}
}
}
Callback for automatic signature
{
"pc_callback": {
"type": "transaction_callback",
"result": {
"error_message": "Success",
"error_code": 0
},
"version": 3,
"transaction_callback": {
"transaction_id": "f84f2749-75dd-48f9-a0e9-9aaaf99cfa9d",
"check_time": 1576678302,
"autosign": {
"signature": "3045022100cab15bbb76703230ea1c7f931bd2b131240b4262b85df6b44bb6c7fd10e61593022063403a4dce33e139f2cf75bd424f07933ad7e796721aa45ce02d02f9a56a581a",
"gost_imit": "84f6870808f423efa533ced9098ecd6b541622eb26ea398d2b39e48825907f94",
"scoring": {
"gib_sb": {
"score": 0,
"scoreLevel": "NO_RISK"
}
}
}
}
}
}
Callback sample for CMS signature
{
"pc_callback": {
"type": "transaction_callback",
"result": {
"error_message": "Success",
"error_code": 0
},
"version": 3,
"transaction_callback": {
"transaction_id": "10825d5c-a196-480a-be99-0d88ac885d4a",
"check_time": 1597324289,
"confirmation": {
"confirm_code": "9add6ffbafe8afcfa94644739ea9ada9fd08d233a3d32d37f1405ddb7019572a",
"signature": "3045022100fab6c7d84d5501a9d967c8835b0fbe2929f0dc06ee8cc147292e63bc0c08ebf302207f8b90997000a2eb75e9ba28f924dada6b264997afee0f146b8409c0fe179bfa",
"cms_data": "MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQExDTALBglghkgBZQMEAgEwCwYJKoZIhvcNAQcBoIIEiDCCBIQwggJsoAMCAQICAhAhMA0GCSqGSIb3DQEBCwUAMHoxCzAJBgNVBAYTAlJVMQ8wDQYDVQQIDAZNb3Njb3cxFjAUBgNVBAoMDVNhZmVUZWNoIEx0ZC4xIDAeBgNVBAMMF09wZW5TU0wgSW50ZXJtZWRpYXRlIENBMSAwHgYJKoZIhvcNAQkBFhF0ZWNoQHNhZmUtdGVjaC5ydTAeFw0yMDA4MTMxMjUzMDlaFw0yMTA4MjMxMjUzMDlaMFoxCzAJBgNVBAYTAlNHMRIwEAYDVQQIDAlTaW5nYXBvcmUxEjAQBgNVBAcMCVNpbmdhcG9yZTEPMA0GA1UECgwGQWlyb21lMRIwEAYDVQQDDAlUZXN0IFVzZXIwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQWqMiUTQcKhNaReblx54iObGzcpmwffvl2+d3iJ8V7uf6\/wpTvVMTuHRtBshucwwZ1kHvE7Y4Bv6aDU57u9lqjo4H+MIH7MAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFKrDj1wRe681Yn6ud4yZETQWgySLMB8GA1UdIwQYMBaAFEkMJKbw+43P5sCbeS4LwzcklEkYMA4GA1UdDwEB\/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0cDovL3BjLWRldmVsb3AvY3JsL2ludGVybWVkaWF0ZS5jcmwwDQYJKoZIhvcNAQELBQADggIBAFGns0L29m45lBtc2XBBz3zV7zloQqLCuJ0oCDRPv0D+7QLxyaIOCMAeNiQxdsxN811RsSzPQ+P5YOGmlYELcAX2yegfW2YblOcPwmyG1Ktlo0Jc8ezCPydxiQsmYSvYs1zHpmONoNvfVqf4uZbDnNrbF6FNTQeK5KAqu2rWdiOeBo\/1Yjcse3bcVqKhmf+9j8brCqR6lE1AZoakFLqiKShStj5zxJCvhWIcfUDf31g43gSnIi6q6fXzqRqX4kjtbAY9vfLTpbpmT5MSX2M7hNfnbQQmXrVtPwWFr\/EmXfYq5uCmFe00EZDaenCjGqKzEmT07ME58wspp6MiVwk6yteCsOOMcOPGM\/sf3Af6GAPOSkHH2GUSRWNA1Ri9HTSCfyI0WiMX4VRApDRrr+MKWKCViZb27rouYWzj9h+mT6YrDHHdQ+cW9VJq2b1wIZACy8MmU7c87VTnjW+cv96Ij8aVE4YgOHjfrsYnTNvKqQwZS6I0uFZCXtx51Ti5MUGYKwgUvatFs8D0wSyZVE1zPP\/9rFU9cAac8LbXyW7v3htL5CSr69aTBI392ZnVxBNfm3RzDUxzvBdfgHjra0gJNp6K0iFBAGtCGgcywXd\/fZ8CL0lDLVZBGYIjEQcbbyhWxyfrM2A6OXftMjig0Iyr9qZ7NgR\/whu\/LoH6rKAmNODRMYIB1TCCAdECAQEwgYAwejELMAkGA1UEBhMCUlUxDzANBgNVBAgMBk1vc2NvdzEWMBQGA1UECgwNU2FmZVRlY2ggTHRkLjEgMB4GA1UEAwwXT3BlblNTTCBJbnRlcm1lZGlhdGUgQ0ExIDAeBgkqhkiG9w0BCQEWEXRlY2hAc2FmZS10ZWNoLnJ1AgIQITALBglghkgBZQMEAgGggeQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODEzMTMxMTE5WjAvBgkqhkiG9w0BCQQxIgQg2yLkZUSO3OHM\/1FXLzcChk\/fCj5Yww\/59bWUC4WEPmcweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDAYIKoZIzj0EAwIFAARHMEUCIQD6tsfYTVUBqdlnyINbD74pKfDcBu6MwUcpLmO8DAjr8wIgf4uQmXAAout16boo+STa2msmSZev7g8Ua4QJwP4Xm\/o="
}
}
}
}
Callback sample for declanation
{
"pc_callback": {
"type": "transaction_callback",
"result": {
"error_message": "Success",
"error_code": 0
},
"version": 3,
"transaction_callback": {
"transaction_id": "be18ce51-c963-48ca-b10c-3e99291634a9",
"check_time": 1576678303,
"declanation": {
"decline_reason": "not authorized",
"decline_code": "3506b6a24c24ab106671b98e8efc031c1c75890df2d306ff544e1048434dbc78"
}
}
}
}
This endpoint is used for PC Transactions management.
Application can make following opreations with PC Transactions:
- Create Transaction for confirmation by specified user
- Confirm Transaction with confirmation code, provided by user in offline mode
- Decline Transaction with decline code, provided by user in offline mode
- Get Transaction Information
- Cancel Transaction confirmation
Usual transaction confirmation flow for PC is following:
- Application creates transaction, specifies user, data to be confirmed (signed) and callback address
- PC sends push notification to persons's mobile app with push identifier, registered for user
- Mobile app shows notification for the person with content like "Hey! You have something to sign!"
- Person opens mobile app (PC App or App with PC SDK for mobile)
- Mobile app requests from PC server transactions list and transaction data (from step 1) by secured channel
- Mobile app shows transaction data to the person
- Person confirms (signs) or declines transaction. At this step PC SDK for mobile calculates signature and make request to PC server to confirm transaction with signature
- PC Server verifies signature and, optionally, generates server-side hmac (imit value)
- PC sends callback to Application with verification results and signature
- Application saves signature with initial document. From now the Document is digitally signed.
As you can see, in usual case Application should realize only step 1 and steps 9-10.
The rest actions we can call as magic.
You can find document signing flow in Architecture and Principles document.
To make Step 9 (receive callback) Application should realize HTTP(s) POST endpoint. PC will send POST-request with JSON-object. Callback from PC always will contain pc_callback object with following params
| Parameter | Description |
|---|---|
| type | For transactions always will be transaction_callback |
| result | Result object with description of transaction processing result |
| version | Callback version. Current version is 3 |
| transaction_callback | Callback data |
result object will contain following params
| Parameter | Description |
|---|---|
| error_code | Error code. 0 means no error |
| error_message | Error description |
transaction_callback object will contain details of transaction processing. This object will contain one of following objects: confirmation, declanation, cancelation, autosign. It depends on cause of callback was generated.
| Parameter | Description |
|---|---|
| transaction_id | Identifier of transaction which generated callback |
| check_time | Timestamp of processing |
| confirmation.confirm_code | Confirmation code (symmetric) provided by person's mobile app |
| confirmation.signature | Signature (asymmetric) provided by person's mobile app |
| confirmation.gost_imit | Server-side HMAC also called imit value, optionally generated to comply special legislation |
| confirmation.cms_data | If transaction was created as type CMS (PKI-like), then cms_data will contain CMS Signature (detached) |
| confirmation.scoring | If a user was created with scoring_enabled flag and PC Server has received scoring data from mobile device, then callback will contain scoring object |
| declanation.decline_reason | Decline reason. Can be one of "not autorized", "wrong data", |
| declanation.decline_code | Declanation code (symmetric) provided by person's mobile app |
| cancelation.reason | Reason of transaction cancelation. Can be "time out" or "canceled" |
| autosign.signature | AutoSignature value (asymmetric) provided by person's mobile app during automatic signature process |
| confirmation.scoring | Autosignature object always will contain scoring object |
Create Transaction
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/transactions
method: POST
Request sample
{
"transaction_data":{
"binary_data":"SGVsbG8gV29ybGQhISE=",
"text":"Money transfer to account **№213154254**, amount **$12 000**",
"text_render_type":"markdown"
},
"snippet": {
"text":"account **№213154254**, amount **$12 000**",
"text_render_type": "markdown"
},
"notification_type": "Push",
"callback_url": "http://abs.absnet.local/transaction_callback",
"confirm_code_length": 8,
"ttl": 0,
"extended_check": false,
"autosing_enabled": false
}
Response sample without transaction QR (tranction for Online mode only)
{
"answer_type": "transaction_created",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"transaction_created": {
"transaction_id": "15984319-3f98-4123-b39d-2d0e5a40e8f6",
"user_id": "rest-api-test-4d02bd9e-ac11-4661-86c5-c7c7965e6a4c",
"system_id": "70b5fab6-d3d1-4098-aaf9-450a496855f5",
"extended_check": false,
"autosign_enabled": false,
"pc_transaction_version": 4,
"data_type": "COMBINED",
"confirm_type": "PUSH",
"confirm_code_length": 8,
"ttl": 0,
"status": "initialized"
}
},
"answer_version": 3
}
Response sample with transaction QR (transaction for Online and Offline modes)
{
"answer_type": "transaction_created",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"transaction_created": {
"transaction_id": "db6fc686-c8e0-4edb-95d3-81ce08a07485",
"user_id": "rest-api-test-4d02bd9e-ac11-4661-86c5-c7c7965e6a4c",
"system_id": "70b5fab6-d3d1-4098-aaf9-450a496855f5",
"extended_check": false,
"autosign_enabled": false,
"pc_transaction_version": 4,
"data_type": "TEXT",
"confirm_type": "PUSH",
"confirm_code_length": 8,
"ttl": 0,
"transaction_qr": "R0lGODlhLAEsAfAAAAAAAP... [truncated]",
"status": "initialized"
}
},
"answer_version": 3
}
This request creates a PC transaction with data to be confirmed by a user.
It starts transaction confirmation process as described above.
| Parameter | Default | Mandatory | Description |
|---|---|---|---|
| transaction_data | yes | Object with data to be confirmed (signed) | |
| transaction_data .binary_data |
no | Binary data for the transaction in base64. Must be set at least one of binary_data or text | |
| transaction_data .text |
no | Text for the transaction, max 10Kb length (pay attention at multi-bytes charsets). Must be set at least one of binary_data or text | |
| transaction_data .text_render_type |
raw | no | Pick which render type should be used by mobile app to show the text. Can be markdown or raw |
| snippet | no | Transaction snippet to show short description about data in mobile app | |
| snippet .text |
yes | Short transaction description to show in mobile app. If you create snippet, then snippet.text is mandatory |
|
| snippet .text_render_type |
raw | no | Pick which render type should be used by mobile app to show snippet text. Can be markdown or raw |
| notification_type | Offline | no | Notification type for the transaction. Can be "Push" or "Offline". If set to "Push" value then push-notification will be sent to user's smartphone |
| callback_url | no | URL to POST callback about transaction. If not specified then callback url will be retrieved from system settings. If no callback url specified in system settings then no callback will be sent | |
| transaction_id | no | Custom transaction id, generated by Application. Must be unique within all transactions created in PC | |
| confirm_code_length | 6 | no | Length of confirmation code for offline mode. Can be from 6 to 10 or 64. 64 means short code will be not accepted, e.g. no Offline mode |
| ttl | 0, configurable | no | Time to live for the transaction in seconds. After this time transaction will be declined automatically with "time out" decline reason. 0 means without restrictions |
| extended_check | false | no | If extended check required for the transaction |
| autosign_enabled | false | no | If automatic signature is allowed for this transaction |
| transaction_type | UNDEFINED | no | Specifies transaction type in case if you want to create specialized type of signature |
| url_template | no | If this parameter is set, then QR-code will contain deep-link, created by the template. It can be useful if you process deep-links in your mobile app. In this case generated QR-code can be scanned with mobile phone's camera app, which will call deep-link handler in your app. PC Server will replace following params in template provided: %SYSTEM_ID%, %USER_ID%, %TRANSACTION_ID%, %TRANSACTION_URLENCODED%, %TRANSACTION_BASE64% Example: paycontrol://transaction?transaction_json=%TRANSACTION_URLENCODED% |
|
| app_start_deeplink_template | no | If this parameter is set, then PC Server will generate deep-link to start confirmation process in mobile app via this deep-link. PC Server will replace following params in template provided: %SYSTEM_ID%, %USER_ID%, %TRANSACTION_ID%. Example: paycontrol://start_confirmation?user_id=%USER_ID%&transaction_id=%TRANSACTION_ID% |
|
| app_extra | null | no | Purpose of this parameter is to deliver to a mobile app extra data during transaction confirmation process. This data will be returned via PC Mobile SDK after call PCTransactionsManager.getTransaction() method. For example, this data can be used to provide a deep-link to be called by mobile app after transaction confirmation. Deep-link can open another app or web-browser to continue a customer journey. Format of this data is unspecified and should be negotiated with mobile app. This value can contain following variables, which will be set by PC Server: %SYSTEM_ID%, %USER_ID%, %TRANSACTION_ID%Example of app-extra: "{\"app_callback_deeplink\":\"https://abs.absnet.local/transaction_confirm_results/%SYSTEM_ID%/%USER_ID%/%TRANSACTION_ID%\"}" |
| deeplink_only | false | no | If this value is set to true and url_template is defined, then no QR-code will be generated, but deep-links only |
Transaction types
| Transaction Type | Meaning | Callback field alteration |
|---|---|---|
| UNDEFINED | Default transaction type | |
| LOGIN | Special transaction used for logging by QR-code (Login via QR feature) | |
| PAYMENT | Does not lead to special processing scenarios yet. Just for information purposes. | |
| SIGN_DOCUMENT | Does not lead to special processing scenarios yet. Just for information purposes. | |
| OPERATION | Transaction which is a part of Operation | |
| CSR | A special transaction for constructing a Certificate Signing Request | |
| CMS | CMS Signature (detached) will be created after trasaction signing | CMS signature will be in transaction callback in pc_callback. transaction_callback.confirmation. cms_data |
| Signed PDF will be created after trasaction signing (PDF with included signature and signature stamp) | Signed PDF will be in transaction callback in pc_callback. transaction_callback. confirmation. pdf_binary_data | |
| WITH_BACKEND_CHECK | Transaction with additional check in backend. MUST NOT be used without this check. |
CMS, CSR and PDF transactions can be confirmed via online-mode only.
CMS and PDF transaction types are available only if a user has certificate issued with status CERT_ISSUIED (see PKI endpoint ).
Offline and Online modes
To work in Offline mode PC can generate transaction QR-code to be provided to mobile app via Application.
For use Offline mode Application should realize following steps:
- Application creates transaction, specifies user, data (only transaction_data.text) to be confirmed (signed) and callback address.
transaction_data.textMUST be not more then 2 Kb length (pay attention at multi-bytes charsets), because of this is optimal data length to be encoded via recongnizable QR-code - PC creates transaction and returns to Application transaction QR-code
- Application shows to the user transaction QR to use in Offline mode
- User with PC mobile app (or with mobile app with PC SDK for mobile) in Offline mode scans transaction QR
- PC mobile app generates short confirmation code in Offline mode
- User inputs this code to Application
- Application makes Confirm Transaction request to PC and confirms transaction
Application can use online and offline mode semultaniously in case confirm only transaction text. It means that if user online then he can sign transaction in online mode. If he offline then he scans QR in inputs confirmation code.
You can see how it works at PC Demo page.
Confirm Transaction
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/transactions/{{transaction_id}}/confirm
method: POST
Request sample for Offline mode
{
"confirm_code":"11223344",
"time_sampling_interval": 180
}
Request sample for Online mode (not used in usual cases by Application)
{
"confirm_code":"6aed4a6366dedf1b8188998141630890f095e13f60c9ba9c3a89c121637f278e",
"signature":"3045022100ffb3e2661bfa7f6821435a48924ee4019531a5beb7f46e23ce8924b5a84d8167022052ca4cefd5fc6b66837419aee0483b9bc10fd5113b92b6082b7be0f9c21c7461"
}
Response has
result_onlyobject
This request should be used to confirm transaction in Offline mode or to check Independent Confirm Code for a Transaction
Request Params
| Parameter | Default | Mandatory | Description |
|---|---|---|---|
| confirm_code | - | yes | Offline Confirm Code from Mobile App or Independent Confirm Code |
| time_sampling_interval | 180 | no | Period of Independent Confirm Code validity (in seconds) |
Decline Transaction
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/transactions/{{transaction_id}}/decline
method: POST
Request sample for Offline mode
{
"decline_code":"11223344",
"decline_reason":"not autorized"
}
Request sample for Online mode (not used in usual cases by Application)
{
"decline_code":"6aed4a6366dedf1b8188998141630890f095e13f60c9ba9c3a89c121637f278e",
"decline_reason":"not autorized"
}
Response has
result_onlyobject
This request should be used to decline transaction in Offline mode.
Cancel Transaction
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/transactions/{{transaction_id}}/decline
method: POST
Request sample for Offline mode
{
"decline_reason":"canceled"
}
Response has
result_onlyobject
This request should be used to cancel transaction confirmation.
Get Transactions List
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/transactions/get_list
method: GET
Request does not contain params
Response sample
{
"answer_type": "transaction_list",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"transaction_list": [
"0926d09e-3c23-4cdc-b744-e59e1be1161f",
"15984319-3f98-4123-b39d-2d0e5a40e8f6",
"db6fc686-c8e0-4edb-95d3-81ce08a07485"
]
},
"answer_version": 3
}
This request should be used to get list of transactions for the user.
Response contains transaction_list object with list of transaction identifiers.
Get Transactions List for automatic confirm (autosign)
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/transactions/get_autoconfirm_list
method: GET
Request does not contain params
Response sample
{
"answer_type": "transaction_list",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"transaction_list": [
"0926d09e-3c23-4cdc-b744-e59e1be1161f",
"15984319-3f98-4123-b39d-2d0e5a40e8f6",
"db6fc686-c8e0-4edb-95d3-81ce08a07485"
]
},
"answer_version": 3
}
This request should be used to get list of transactions with autosign_enabled flag for the user.
Response contains transaction_list object with list of transaction identifiers.
Get Transaction Details
Common Transaction Details
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/transactions/{{transaction_id}}
method: GET
Request does not contain params
Response sample
{
"answer_type": "transaction_info",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"transaction_info": {
"transaction_id": "0926d09e-3c23-4cdc-b744-e59e1be1161f",
"user_id": "rest-api-test-4d02bd9e-ac11-4661-86c5-c7c7965e6a4c",
"system_id": "70b5fab6-d3d1-4098-aaf9-450a496855f5",
"extended_check": false,
"autosign_enabled": false,
"pc_transaction_version": 4,
"data_type": "TEXT",
"confirm_type": "PUSH",
"confirm_code_length": 8,
"ttl": 0,
"transaction_qr": "R0lGODlhLAEsAfAAAAAAAP... [truncated]",
"status": "pushSent"
}
},
"answer_version": 3
}
This request should be used to get transaction details, including transaction status.
Statuses can be initialized, pushSent, dataSent, confirmed, declined.
If transaction data_type is TEXT then transaction_qr will be returned in response. In other case (data_type is BINARY or COMBINED) transaction_qr will be absent.
Confirmed Transaction Details
Response sample for confirmed transaction
{
"answer_type": "transaction_info",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"transaction_info": {
"transaction_id": "5993a5f4-89a1-4b0d-bf41-31432cbd822b",
"confirm_attempts": [
{
"data_hash": "8b1308f432db5077ddeeb6158a79bfc04d5d6c0cf5c2462bd36c222fde848741",
"event_id": 30197,
"confirm_result": "SUCCESS",
"signature": "3045022100d788d6df45b27c987984ca291c9e6f67095896e9d2ba77b252012bebb223326c022048c05f2dd7a6f54936a1b2942fdedde693427366d7ddb9e38fd725e3655f9531",
"confirm_code": "db5b64e0e124594002cde5c7300087e0e1f99c55e042017f0ac17f8588d0a2a0",
"created_at": 1572098520,
"confirm_attempt_id": 2369
}
],
"pc_transaction_version": 4,
"user_id": "stable50-066ff3c3-1fa5-4d18-9dda-fd742d7b2f0a",
"system_id": "598b350f-95c9-4e11-88c1-5866e98a145c",
"extended_check": false,
"autosign_enabled": false,
"data_type": "EMPTY",
"confirm_code_length": -1,
"confirm_type": "PUSH",
"ttl": 300,
"status": "confirmed"
}
},
"answer_version": 3
}
If transaction was confirmed or there were attempts to confirm the transaction, answer will contain confirm_attempts objects.
Transaction Details with scoring results
Response sample for confirmed transaction
{
"answer_type": "transaction_info",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"transaction_info": {
"transaction_id": "e4095753-4fc1-48e2-87c0-309e47118871",
"confirm_attempts": [
{
"data_hash": "8165423c30be38c6f343bf56e09f40c510aa63f7abeb6b9b409ce5cb58483a2d",
"event_id": 30217,
"confirm_result": "SUCCESS",
"signature": "30450221009086600e6fb7f524d621c8ee31e072932dba55fe3133ce43e64f339ade15806b0220547ffbdfc05e5113f991de56f5bc70e85100c9ccc33e0811e47d4f430a8f7c11",
"confirm_code": "064cdc0633a0a99e7eb435ff0e69a51636b4c1ff151598ef4a28b64f687a1b1f",
"scoring_results": {
"gib_sb": {
"score": 0,
"scoreLevel": "NO_RISK"
}
},
"scoring_settings": {
"gib_sb": {
"session_id": "gl6y9x8s7nippSX51nn184t+BusJkY51DPMEEE1eQlsfS5bNrrsf9eDuoVWp4FnHuQFspLGAJdv1BiJyATzu+doZc0Ilx7lm9J7o93YZfaagTfPXkIoQM9B4cHV4JwUOWJUza9WfhH9hPsjHnpno0JrY"
}
},
"created_at": 1572169705,
"confirm_attempt_id": 2370
}
],
"pc_transaction_version": 4,
"user_id": "rest-api-test-87420d64-802f-4d6b-92a5-6f3b27c13729",
"system_id": "598b350f-95c9-4e11-88c1-5866e98a145c",
"extended_check": false,
"autosign_enabled": false,
"data_type": "EMPTY",
"confirm_code_length": 8,
"confirm_type": "PUSH",
"ttl": 0,
"status": "confirmed"
}
},
"answer_version": 3
}
If a user was created with scoring_enabled flag and PC Server has received scoring data from mobile device, then a confirm_attempt object will contain scoring_results and scoring_settings objects.
Content of this objects will be depended from scoring settings for PC instance.
For know PC Server supports Group-IB Secure Bank scoring mechanisms.
Get Scoring Details for confirmation attempt
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/transactions/attempts/{{attempt_id}}/scoring_details
method: GET
Request does not contain params
Response sample
{
"answer_type": "scoring_details",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"scoring_details": {
"gib_sb": {
"data": {
"alerts": [],
"score": 0,
"info": [
1
],
"score_level": "no"
},
"status": 200
}
}
},
"answer_version": 3
}
To get scoring details directly from scoring provider you should use this request. {{attempt_id}} can be extracted from transaction_info.confirm_attempts[x].confirm_attempt_id value.
The response will contain raw answer from scoring provider.
Content of this objects will be depended from scoring settings for PC instance.
For know PC Server supports Group-IB Secure Bank scoring mechanisms.
Get Transaction Data
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/transactions/{{transaction_id}}/get_data
method: GET
Request does not contain params
Response sample
{
"answer_type": "transaction_data",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"transaction_data": {
"extended_check": false,
"text": "Money transfer to account №213154254, amount $12 000",
"text_render_type": "raw",
"binary_data_url": "[EXTERNAL URL TO GET BINARY DATA]",
"confirm_code_length": 8,
"snippet": {
"text":"account **№213154254**, amount **$12 000**",
"text_render_type": "markdown"
},
}
},
"answer_version": 3
}
This request returns transaction data.
If binary data exists in the transaction, then transaction_data will contain binary_data_url. This url should be used to get binary data externally, using PC External endpoints.
Application should use Get Transaction Binary Data endpoint to get transaction binary data.
Get Transaction Binary Data
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/transactions/{{transaction_id}}/get_binary_data
method: GET
Request does not contain params
Response will be binary data with
application/octet-streammedia type
This request returns transaction binary data (if exists).
Get Signed PDF (from database)
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/transactions/{{transaction_id}}/get_pdf
method: GET
Request does not contain params
Response will be PDF data with
application/octet-streammedia type with filenametransaction_id.pdf
This request returns signed PDF for transaction with type PDF (if exists in PC database).
The request re-builds signed PDF from source PDF and stored CMS signature.
If PC Server configured to clean transaction data after confirmation, then this request will return exception.
In this case you can use POST request to this end-point (see Rebuild Signed PDF ).
Rebuild Signed PDF
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/transactions/{{transaction_id}}/get_pdf
method: POST
Request must contain source PDF data.
application/octet-streammedia type must be usedResponse will be PDF data with
application/octet-streammedia type with filenametransaction_id.pdf
This request returns signed PDF for transaction with type PDF.
The request re-builds signed PDF from source PDF from the POST-data and stored CMS signature.
Operations endpoint
Callback sample for Operation
{
"pc_callback": {
"type": "operation_callback",
"result": {
"error_message": "Success",
"error_code": 0
},
"version": 3,
"operation_callback": {
"operation_id": "3c98041f-d97c-455b-ab7d-6ddf1cde0d58",
"transactions": [
{
"transaction_id": "55a8c34b-d976-43b0-8adb-9c02945b3e4e",
"check_time": 1588063725,
"confirmation": {
"confirm_code": "6aed4a6366dedf1b8188998141630890f095e13f60c9ba9c3a89c121637f278e",
"signature": "3045022100ffb3e2661bfa7f6821435a48924ee4019531a5beb7f46e23ce8924b5a84d8167022052ca4cefd5fc6b66837419aee0483b9bc10fd5113b92b6082b7be0f9c21c7461"
},
"result": {
"error_message": "Success",
"error_code": 0
}
},
{
"transaction_id": "286395e7-b595-41ec-bb36-268084e9f228",
"check_time": 1588063725,
"confirmation": {
"confirm_code": "6aed4a6366dedf1b8188998141630890f095e13f60c9ba9c3a89c121637f278e",
"signature": "3045022100ffb3e2661bfa7f6821435a48924ee4019531a5beb7f46e23ce8924b5a84d8167022052ca4cefd5fc6b66837419aee0483b9bc10fd5113b92b6082b7be0f9c21c7461"
},
"result": {
"error_message": "Success",
"error_code": 0
}
},
{
"transaction_id": "22289902-9ccd-44a6-a9f1-54b1372a0651",
"declanation": {
"decline_reason": "not autorized",
"decline_code": "6aed4a6366dedf1b8188998141630890f095e13f60c9ba9c3a89c121637f278e"
},
"check_time": 1588063725,
"result": {
"error_message": "Decline code is incorrect",
"error_code": 244
}
},
{
"transaction_id": "9f7e24db-ebce-44b4-af0b-333bf4d31a19",
"check_time": 1588063725,
"cancelation": {
"reason": "canceled"
},
"result": {
"error_message": "Success",
"error_code": 0
}
}
],
"status": "processed"
}
}
}
This endpoint is used for PC Operations management.
In terms of PC, Operations is a group of Transactions.
Application developer can create Operation to manage a few transactions as a group. It means that those transactions will have the same params, notification settings, confirmation settings and so on.
Moreover, Operation
- has it's own callback
- allows to process transactions (confirm or decline) with one request from mobile app
- allows partially processing
- allows to add transactions to an Operation
Operations are processed by PC Server as set of Transactions, excluding callbacks. During Operations processing PC server does not send callback for each transaction, but callback will be sent as a result of Operation processing.
Operation callback will be like following
| Parameter | Description |
|---|---|
| type | For transactions always will be operation_callback |
| result | Result object with description of operation processing result |
| version | Callback version. Current version is 3 |
| operation_callback | Callback data |
result` object will contain following params
| Parameter | Description |
|---|---|
| error_code | Error code. 0 means no error |
| error_message | Error description |
operation_callback object will contain following data
| Parameter | Description |
|---|---|
| operation_id | Operation Id |
| status | Operation status after processing (see statuses in Get Operation Info request) |
| transactions | Set of results of transactions processing. Content is the same as for transactions callback |
Create Operation
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/operations
method: POST
Request sample
{
"description": {
"text": "Payments registry #1",
"text_render_type": "raw"
},
"notification_type": "Push",
"callback_url": "http://abs.absnet.local/operation_callback",
"ttl": 600,
"extended_check": false,
"transactions": [
{
"transaction_data": {
"binary_data":"SGVsbG8gV29ybGQhISE=",
"text":"Money transfer to account №11112222, amount $1 000",
"text_render_type": "raw"
},
"snippet": {
"text":"account №11112222, $12 000",
"text_render_type": "raw"
},
"index" : 1
},
{
"transaction_data": {
"binary_data":"SGVsbG8gV29ybGQhISE=",
"text":"Money transfer to account №33334444, amount $3 000",
"text_render_type": "raw"
},
"snippet": {
"text":"account №33334444, $3 000",
"text_render_type": "raw"
},
"index" : 2
}
]
}
Response sample
{
"answer_type": "operation_created",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"operation_created": {
"notification_type": "Push",
"pc_operation_version": 1,
"user_id": "stage-v52-flex-95d2f552-516a-4427-894f-c1f21b7fc605",
"system_id": "94b309be-5d2c-456e-9cde-82ea0b65e4ed",
"extended_check": false,
"operation_id": "db78e117-ed39-4ba9-9fee-8b5f4603bd67",
"transactions": [
{
"transaction_id": "4e12720d-402e-4660-8445-2b778252698f",
"index": 1
},
{
"transaction_id": "2c51539d-95b4-4942-9665-e6f95d1986c3",
"index": 2
}
],
"ttl": 600,
"status": "push_sent"
}
},
"answer_version": 3
}
This request creates a PC Operation with set of transactions to be confirmed by a user.
Please, see Transactions endpoint description for confirmation process description.
| Parameter | Default | Mandatory | Description |
|---|---|---|---|
| description | no | Short description for an Operation (group of transactions) to be shown on mobile device | |
| description.text | yes | Description text | |
| description.text_render_type | raw | no | Pick which render type should be used by mobile app to show the text. Can be markdown or raw |
| notification_type | Offline | no | Notification type for the Operation. Can be "Push" or "Offline". If set to "Push" value then push-notification will be sent to user's smartphone |
| callback_url | no | URL to POST callback about Operation. If not specified then callback url will be retrieved from system settings. If no callback url specified in system settings then no callback will be sent | |
| ttl | 0, configurable | no | Time to live for transactions in the Operation in seconds. After this time transactions will be declined automatically with "time out" decline reason. 0 means without restrictions |
| extended_check | false | no | If extended check required for transactions in the Operation |
| confirm_code_length | - | no | Length of confirmation code for offline mode for transactions in the operation. Can be from 6 to 10 or 64. 64 means short code will be not accepted, e.g. no Offline mode. If this value is not set, then any allowed length of confirmation code will be accepted for transactions in the operation |
| app_extra | null | no | Purpose of this parameter is to deliver to a mobile app extra data during operation confirmation process. This data will be returned via PC Mobile SDK after call PCOperationssManager.getOperation() method. For example, this data can be used to provide a deep-link to be called by mobile app after transaction confirmation. Deep-link can open another app or web-browser to continue a customer journey. Format of this data is unspecified and should be negotiated with mobile app. This value can contain following variables, which will be set by PC Server: %SYSTEM_ID%, %USER_ID%, %OPERATION_ID%Example of app-extra: "{\"app_callback_deeplink\":\"https://abs.absnet.local/operation_confirm_results/%SYSTEM_ID%/%USER_ID%/%OPERATION_ID%/\"}" |
| transactions | yes | Set of transactions (one or more) to be confirmed (singed) within an Operation | |
| transactions.transaction_data | yes | Data for transaction. Content the same as transaction_data in Create Transaction request |
|
| transactions.snippet | no | Snippet for transaction. Content the same as snippet in Create Transaction request |
|
| transaction.index | yes | Index in set of transactions to sort the response (to assign returned transaction_id with transaction_data in the response). Must be unique increased digit from 1 |
Add transaction to Operation
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/operations/{{operation_id}}
method: POST
Request sample
{
"transactions": [
{
"transaction_data": {
"binary_data":"SGVsbG8gV29ybGQhISE=",
"text":"Money transfer to account №55556666, amount $500",
"text_render_type": "raw"
},
"snippet": {
"text":"account №55556666, $12 000",
"text_render_type": "raw"
},
"index" : 1
},
{
"transaction_data": {
"binary_data":"SGVsbG8gV29ybGQhISE=",
"text":"Money transfer to account №77778888, amount $100",
"text_render_type": "raw"
},
"snippet": {
"text":"account №77778888, $13 000",
"text_render_type": "markdown"
},
"index" : 2
}
]
}
Response sample
{
"answer_type": "operation_update",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"operation_update": {
"pc_operation_version": 1,
"user_id": "stage-v52-flex-95d2f552-516a-4427-894f-c1f21b7fc605",
"system_id": "94b309be-5d2c-456e-9cde-82ea0b65e4ed",
"transactions": [
{
"transaction_id": "22289902-9ccd-44a6-a9f1-54b1372a0651",
"index": 1
},
{
"transaction_id": "9f7e24db-ebce-44b4-af0b-333bf4d31a19",
"index": 2
}
]
}
},
"answer_version": 3
}
This request is used to add transactions (one or more) to existing operation.
| Parameter | Default | Mandatory | Description |
|---|---|---|---|
| transactions | yes | Set of transactions (one or more) to be confirmed (singed) within an Operation | |
| transactions.transaction_data | yes | Data for transaction. Content the same as transaction_data in Create Transaction request |
|
| transactions.snippet | no | Snippet for transaction. Content the same as snippet in Create Transaction request |
|
| transaction.index | yes | Index in set of transactions to sort the response (to assign returned transaction_id with transaction_data in the response). Must be unique increased digit from 1 |
Response contains set of transation_id's of created transactions.
Get Operation Info
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/operations/{{operation_id}}
method: GET
Response sample
{
"answer_type": "operation_info",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"operation_info": {
"callback_url": "http://abs.absnet.local/operation_callback",
"notification_type": "Push",
"pc_operation_version": 1,
"user_id": "stage-v52-flex-95d2f552-516a-4427-894f-c1f21b7fc605",
"system_id": "94b309be-5d2c-456e-9cde-82ea0b65e4ed",
"extended_check": false,
"operation_id": "3c98041f-d97c-455b-ab7d-6ddf1cde0d58",
"transactions": [
{
"transaction_id": "55a8c34b-d976-43b0-8adb-9c02945b3e4e",
"status": "initialized"
},
{
"transaction_id": "286395e7-b595-41ec-bb36-268084e9f228",
"status": "initialized"
}
],
"ttl": 600,
"status": "push_sent"
}
},
"answer_version": 3
}
This request should be used to get operation info, uncluding status of the operation and each transaction in the operation.
If you need detailed information about exact transaction then you should use Get Transaction Details request with transaction_id from an operation.
Operation status can be
| Status | Description |
|---|---|
| initialized | Operation created |
| push_sent | push-notification sent to a user's mobile device |
| processed_partially | more then 0 but less then all of transactions in the operation are confirmed or declined |
| processed | all of transactions in the operation are confirmed or delined |
Get Operations List
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/operations/get_list
method: GET
Response sample
{
"answer_type": "operations_list",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"operations_list": [
"db78e117-ed39-4ba9-9fee-8b5f4603bd67",
"3c98041f-d97c-455b-ab7d-6ddf1cde0d58"
]
},
"answer_version": 3
}
Request to get the list of operations in status initialized, push_sent or partially_procced.
Get Operation Data
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/operations/{{operation_id}}/get_data
method: GET
Response sample
{
"answer_type": "operation_data",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"operation_data": {
"extended_check": false,
"description": {
"text_render_type": "raw",
"text": "Payments registry #1"
},
"transactions": [
{
"transaction_id": "55a8c34b-d976-43b0-8adb-9c02945b3e4e",
"snippet": {
"text_render_type": "markdown",
"text": "account №11112222, $12 000"
},
"transaction_data": {
"binary_data_url": "https://stage.paycontrol.org/52/pc-client-api/jsonrequest_v3/94b309be-5d2c-456e-9cde-82ea0b65e4ed/users/stage-v52-flex-95d2f552-516a-4427-894f-c1f21b7fc605/transactions/55a8c34b-d976-43b0-8adb-9c02945b3e4e/get_binary_data",
"text_render_type": "markdown",
"text": "Money transfer to account №11112222, amount $1 000"
}
},
{
"transaction_id": "286395e7-b595-41ec-bb36-268084e9f228",
"snippet": {
"text_render_type": "markdown",
"text": "account №33334444, $3 000"
},
"transaction_data": {
"binary_data_url": "https://stage.paycontrol.org/52/pc-client-api/jsonrequest_v3/94b309be-5d2c-456e-9cde-82ea0b65e4ed/users/stage-v52-flex-95d2f552-516a-4427-894f-c1f21b7fc605/transactions/286395e7-b595-41ec-bb36-268084e9f228/get_binary_data",
"text_render_type": "markdown",
"text": "Money transfer to account №33334444, amount $3 000"
}
}
]
}
},
"answer_version": 3
}
This request allows to get data for an operation:
- operation description
transaction_idfor each transaction- data for each transaction, including
textandbinary_data_url(if present) - snippet for each transaction (if present)
Usually this request is used by mobile part.
Process Operation
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/operations/{{operation_id}}/process
method: POST
Request sample
{
"confirm": [
{
"transaction_id": "cce39f31-27ab-4c9b-9a39-38866619c7d9",
"confirm_code": "6aed4a6366dedf1b8188998141630890f095e13f60c9ba9c3a89c121637f278e",
"signature": "3045022100ffb3e2661bfa7f6821435a48924ee4019531a5beb7f46e23ce8924b5a84d8167022052ca4cefd5fc6b66837419aee0483b9bc10fd5113b92b6082b7be0f9c21c7461"
},
{
"transaction_id": "15984319-3f98-4123-b39d-2d0e5a40e8f8",
"confirm_code": "6aed4a6366dedf1b8188998141630890f095e13f60c9ba9c3a89c121637f278e",
"signature": "3045022100ffb3e2661bfa7f6821435a48924ee4019531a5beb7f46e23ce8924b5a84d8167022052ca4cefd5fc6b66837419aee0483b9bc10fd5113b92b6082b7be0f9c21c7461"
}
],
"decline": [
{
"transaction_id": "15984319-3f98-4123-b39d-2d0e5a40e8f9",
"decline_code": "6aed4a6366dedf1b8188998141630890f095e13f60c9ba9c3a89c121637f278e",
"decline_reason": "not autorized"
},
{
"transaction_id": "05031b3e-9eee-4e7b-9adf-90cc79def383",
"decline_reason": "canceled"
}
]
}
Response sample
{
"answer_type": "operation_processed",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"operation_processed": [
{
"transaction_id": "55a8c34b-d976-43b0-8adb-9c02945b3e4e",
"result": {
"error_message": "Success",
"error_code": 0
}
},
{
"transaction_id": "286395e7-b595-41ec-bb36-268084e9f228",
"result": {
"error_message": "Success",
"error_code": 0
}
},
{
"transaction_id": "22289902-9ccd-44a6-a9f1-54b1372a0651",
"result": {
"error_message": "Decline code is incorrect",
"error_code": 244
}
},
{
"transaction_id": "9f7e24db-ebce-44b4-af0b-333bf4d31a19",
"result": {
"error_message": "Success",
"error_code": 0
}
}
]
},
"answer_version": 3
}
This request is used to process (confirm or decline) transactions within an operation.
Usually this method is used my mobile app (PC Mobile SDK), but it can be used to cancel transaction in an operation as well.
To cancel operation you should fill decline set with transaction id and decline_reason: canceled, like in request sample.
| Parameter | Mandatory | Description |
|---|---|---|
| confirm | no | set of requests to confirm transactions |
| confirm.transaction_id | yes | transaction id to be confirmed |
| confirm.confirm_code | yes | symmetric confirmation code (generated by PC Mobile SDK) |
| confirm.signature | depends on | asymmetric signature (generated by PC Mobile SDK) |
| decline | no | set of requests to decline transactions |
| decline.transaction_id | yes | transaction id to be declined |
| decline.decline_code | depends on | if decline_reason is not authorized or wrong data then this is symmetric decline code (generated by PC Mobile SDK) |
| decline.decline_reason | yes | decline reason. Can be not authorized, wrong data, timeout or canceled |
The response will contain processing result for each transaction.
Independent Confirm Codes endpoints
This endpoints set can be used to generate independent confirmation codes.
Generated codes can be sent via independent channel (like SMS or Push-notification) without using PC Server or PC Mobile SDK.
The workflow looks like following:
- An Application (back-end) has a Data to be confirmed
- The Application creates Confirm Code with one of endpoints bellow
- The Application sends Confirm Code to a User via independent channel (SMS/Push/Other)
- The User receives Confirm Code and provides it to the Application
- The Application verifies the Confirm Code with one of endpoints bellow
In this case:
- Confirm Code is strictly linked with the Data, time and a Key. It's not randomly generated
- An Application doesn't have to remember or hold Confirm Code to verify it
There are few options how to use Independent Confirm Codes
- with PC transaction
- without PC transaction, but for a PC User
- common Confirm Code
With Transaction
In case of using this option, Application has to
- create PC User for each own User
- create and remember PC Transaction identifier for each Confirm Code
To process confirmation Application does following steps:
- Creates a transaction with
notification_type: Offlineand requiredconfirm_code_length - Calls Create Confirm Code for a Transaction method to create Confirm Code
- Calls Confirm transaction method to verify Confirm Code
Create Confirm Code for a Transaction
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/transactions/{{transaction_id}}/gen_confirm_code
method: POST
Request Sample
{
"time_sampling_interval": 180
}
Response Sample
{
"answer_type": "confirm_code",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"confirm_code": "815034"
},
"answer_version": 3
}
This endpoint is used to generate Confirm Code for a data that is held in a transaction.
| Parameter | Default | Mandatory | Description |
|---|---|---|---|
| time_sampling_interval | 180 | no | Period of Confirm Code validity (in seconds) |
Response contains confirm_code value to be sent to a User
Without Transaction, but for a PC User
In this case Application has to create PC User for each own User.
To process confirmation Application does following steps:
- Calls Create Confirm Code for PC User method to create Confirm Code
- Calls Check Confirm Code for PC User method to verify Confirm Code
Create Confirm Code for PC User
endpoint: {{pc-server-api}}/{{system_id}}/codes/gen_confirm_code
method: POST
Request Sample
{
"user_id": "{{user_id}}",
"transaction_data":{
"binary_data":"SGVsbG8gV29ybGQhISE=",
"text":"Money transfer to account **№213154254**, amount **$12 000**",
},
"time_sampling_interval": 180,
"confirm_code_length": 8
}
Response Sample
{
"answer_type": "confirm_code",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"confirm_code": "08717082"
},
"answer_version": 3
}
This endpoint is used to generate Confirm Code that is unique for the PC User
Request params
| Parameter | Default | Mandatory | Description |
|---|---|---|---|
| user_id | - | yes | PC User ID to generate Confirm Code |
| transaction_data | - | yes | Data to be confirmed |
| transaction_data.binary_data | - | no | Binary data to be confirmed in base64. Must be set at least one of binary_data or text |
| transaction_data.text | - | no | Text to be confirmed, max 10Kb length (pay attention at multi-bytes charsets). Must be set at least one of binary_data or text |
| time_sampling_interval | 180 | no | Period of Confirm Code validity (in seconds) |
| confirm_code_length | 6 | no | Length of Confirm Code. Can be from 6 to 10 |
Response contains confirm_code value to be sent to a User
Check Confirm Code for PC User
endpoint: {{pc-server-api}}/{{system_id}}/codes/check_confirm_code
method: POST
Request Sample
{
"user_id": "{{user_id}}",
"transaction_data":{
"binary_data":"SGVsbG8gV29ybGQhISE=",
"text":"Money transfer to account **№213154254**, amount **$12 000**",
},
"time_sampling_interval": 180,
"confirm_code": "08717082"
}
Response has
result_onlyobject
This request is used to verify Confirm Code for provided Data and PC User
Request params
| Parameter | Default | Mandatory | Description |
|---|---|---|---|
| user_id | - | yes | PC User ID to verify Confirm Code |
| transaction_data | - | yes | Data to be verified |
| transaction_data.binary_data | - | no | Binary data to be verified in base64. Must be set at least one of binary_data or text |
| transaction_data.text | - | no | Text to be verified, max 10Kb length (pay attention at multi-bytes charsets). Must be set at least one of binary_data or text |
| time_sampling_interval | 180 | no | Period of Confirm Code validity (in seconds) |
| confirm_code | - | yes | Confirmation Code to be verified |
Common Confirm Code
In case of using this option, Application does not have to do anything except of generating Confirm Codes and verifying them.
To process confirmation Application does following steps:
- Calls Create Common Confirm Code method to create Confirm Code
- Calls Check Common Confirm Code method to verify Confirm Code
Create Common Confirm Code
endpoint: {{pc-server-api}}/{{system_id}}/codes/gen_confirm_code
method: POST
Request Sample
{
"transaction_data":{
"binary_data":"SGVsbG8gV29ybGQhISE=",
"text":"Money transfer to account **№213154254**, amount **$12 000**",
},
"time_sampling_interval": 180,
"confirm_code_length": 8
}
Response Sample
{
"answer_type": "confirm_code",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"confirm_code": "08717082"
},
"answer_version": 3
}
This endpoint is used to generate Confirm Code that is unique for the PC User
Request params
| Parameter | Default | Mandatory | Description |
|---|---|---|---|
| transaction_data | - | yes | Data to be confirmed |
| transaction_data.binary_data | - | no | Binary data to be confirmed in base64. Must be set at least one of binary_data or text |
| transaction_data.text | - | no | Text to be confirmed, max 10Kb length (pay attention at multi-bytes charsets). Must be set at least one of binary_data or text |
| time_sampling_interval | 180 | no | Period of Confirm Code validity (in seconds) |
| confirm_code_length | 6 | no | Length of Confirm Code. Can be from 6 to 10 |
Response contains confirm_code value to be sent to a User
Check Common Confirm Code
endpoint: {{pc-server-api}}/{{system_id}}/codes/check_confirm_code
method: POST
Request Sample
{
"transaction_data":{
"binary_data":"SGVsbG8gV29ybGQhISE=",
"text":"Money transfer to account **№213154254**, amount **$12 000**",
},
"time_sampling_interval": 180,
"confirm_code": "08717082"
}
Response has
result_onlyobject
This request is used to verify Confirm Code for provided Data and PC User
Request params
| Parameter | Default | Mandatory | Description |
|---|---|---|---|
| transaction_data | - | yes | Data to be verified |
| transaction_data.binary_data | - | no | Binary data to be verified in base64. Must be set at least one of binary_data or text |
| transaction_data.text | - | no | Text to be verified, max 10Kb length (pay attention at multi-bytes charsets). Must be set at least one of binary_data or text |
| time_sampling_interval | 180 | no | Period of Confirm Code validity (in seconds) |
| confirm_code | - | yes | Confirmation Code to be verified |
PKI endpoint
If PC Server is configured to work with PKI, then this endpoint is used for PKI functions:
- issue certificate
- get certificate status
- revoke certificate
PKI functions are available after a user has finished personalization process, e.g. after PC Server has received user's public key.
Issue certificate
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/pki/create_certificate
method: POST
Request sample
{
"certificate_request": {
"DN": "C=SG,ST=Singapore,L=Singapore,O=Airome,CN=Test User",
"EKU": [
"1.3.6.1.5.5.7.3.2",
"1.3.6.1.5.5.7.3.4"
],
"ca_extra": {
"some_extra": "some_value"
}
},
"request_transaction": {
"transaction_data":{
"text": "Confirm certificate request: \n**C=SG,ST=Singapore,L=Singapore,O=Airome,CN=Test User**",
"text_render_type": "markdown"
},
"notification_type": "Push",
"callback_url": "http://abs.absnet.local/transaction_callback",
"ttl": 0
}
}
Response sample
{
"answer_type": "certificate_request_created",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"certificate_request_created": {
"transaction_id": "06a2a194-d1ad-4de0-a877-4f5d77a6b31d",
"system_id": "548daaa8-1ec3-465b-8543-917424ab5ffe",
"autosign_enabled": false,
"pc_transaction_version": 4,
"confirm_code_length": 0,
"type": "CSR",
"ttl": 0,
"callback_url": "https://paycontrol.org/receive_request/",
"user_id": "rest-api-test-926c3ecf-a683-4510-be0d-d1d9d40ddead",
"extended_check": false,
"data_type": "COMBINED",
"text_render_type": "markdown",
"confirm_type": "PUSH",
"status": "initialized"
}
},
"answer_version": 3
}
This request starts certificate issuing process, which contains following steps
- PC Server creates
CertificateRequestInfo(see RFC 2986) structure with specified- Distinguished Name
- Extended Key Usage
- User's public key
- PC Server creates a transaction for specified user with
- text data, specified in
request_transaction.transaction_data.text - binary data with CertificateRequestInfo
- text data, specified in
- PC Client (mobile app) confirms the transaction, e.g. generates digital signature for
CertificateRequestInfo - PC Server creates
CertificateRequest(PKCS#10) - PC Server executes certificate issuing process with configured Certification Authority (CA) with created
CertificateRequest. If CA requires some additional data, then values will be gotten fromca_extraparameter of the request - PC Server verifies issued certificate
After step 6 PC Server sends a callback as for regular transaction with 2 additional fields: csr_data and certificate.
| Parameter | Default | Mandatory | Description |
|---|---|---|---|
| certificate_request | y | Parameters for certificate request | |
| certificate_request.DN | y | Distinguished Name for certificate request | |
| certificate_request.EKU | y | Extended key usage for certificate request | |
| request_transaction | y | Parameters for PC Transaction, which will be created to sign CertificateRequestInfo. Corresponds to regular transaction parameters. |
An answer will contain certificate_request_created object, which corresponds to transaction creation response.
Get status
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/pki/get_certificate_status
method: GET
Response sample
{
"answer_type": "certificate_status",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"certificate_status": {
"cert_request": "MIIBETCBugIBADBaMQswCQYDVQQGEwJTRzESMBAGA1UECAwJU2luZ2Fwb3JlMRIwEAYDVQQHDAlTaW5nYXBvcmUxDzANBgNVBAoMBkFpcm9tZTESMBAGA1UEAwwJVGVzdCBVc2VyMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEFqjIlE0HCoTWkXm5ceeIjmxs3KZsH375dvnd4ifFe7n+v8KU71TE7h0bQbIbnMMGdZB7xO2OAb+mg1Oe7vZaozAKBggqhkjOPQQDAgNGADBDAh9GsJ9/EYGoLQ24Z6lYuMNWXH3X+T+ACeK/rfpqI6+kAiAWeZatHpVBMlJTA79Kyu8qHQcCzywqvwECGZIMiTCkFA==",
"certificate": "MIIEhDCCAmygAwIBAgICECEwDQYJKoZIhvcNAQELBQAwejELMAkGA1UEBhMCUlUxDzANBgNVBAgMBk1vc2NvdzEWMBQGA1UECgwNU2FmZVRlY2ggTHRkLjEgMB4GA1UEAwwXT3BlblNTTCBJbnRlcm1lZGlhdGUgQ0ExIDAeBgkqhkiG9w0BCQEWEXRlY2hAc2FmZS10ZWNoLnJ1MB4XDTIwMDgxMzEyNTMwOVoXDTIxMDgyMzEyNTMwOVowWjELMAkGA1UEBhMCU0cxEjAQBgNVBAgMCVNpbmdhcG9yZTESMBAGA1UEBwwJU2luZ2Fwb3JlMQ8wDQYDVQQKDAZBaXJvbWUxEjAQBgNVBAMMCVRlc3QgVXNlcjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABBaoyJRNBwqE1pF5uXHniI5sbNymbB9++Xb53eInxXu5/r/ClO9UxO4dG0GyG5zDBnWQe8TtjgG/poNTnu72WqOjgf4wgfswCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwMwYJYIZIAYb4QgENBCYWJE9wZW5TU0wgR2VuZXJhdGVkIENsaWVudCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUqsOPXBF7rzVifq53jJkRNBaDJIswHwYDVR0jBBgwFoAUSQwkpvD7jc/mwJt5LgvDNySUSRgwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDA3BgNVHR8EMDAuMCygKqAohiZodHRwOi8vcGMtZGV2ZWxvcC9jcmwvaW50ZXJtZWRpYXRlLmNybDANBgkqhkiG9w0BAQsFAAOCAgEAUaezQvb2bjmUG1zZcEHPfNXvOWhCosK4nSgINE+/QP7tAvHJog4IwB42JDF2zE3zXVGxLM9D4/lg4aaVgQtwBfbJ6B9bZhuU5w/CbIbUq2WjQlzx7MI/J3GJCyZhK9izXMemY42g299Wp/i5lsOc2tsXoU1NB4rkoCq7atZ2I54Gj/ViNyx7dtxWoqGZ/72PxusKpHqUTUBmhqQUuqIpKFK2PnPEkK+FYhx9QN/fWDjeBKciLqrp9fOpGpfiSO1sBj298tOlumZPkxJfYzuE1+dtBCZetW0/BYWv8SZd9irm4KYV7TQRkNp6cKMaorMSZPTswTnzCymnoyJXCTrK14Kw44xw48Yz+x/cB/oYA85KQcfYZRJFY0DVGL0dNIJ/IjRaIxfhVECkNGuv4wpYoJWJlvbuui5hbOP2H6ZPpisMcd1D5xb1UmrZvXAhkALLwyZTtzztVOeNb5y/3oiPxpUThiA4eN+uxidM28qpDBlLojS4VkJe3HnVOLkxQZgrCBS9q0WzwPTBLJlUTXM8//2sVT1wBpzwttfJbu/eG0vkJKvr1pMEjf3ZmdXEE1+bdHMNTHO8F1+AeOtrSAk2norSIUEAa0IaBzLBd399nwIvSUMtVkEZgiMRBxtvKFbHJ+szYDo5d+0yOKDQjKv2pns2BH/CG78ugfqsoCY04NE=",
"status": "CERT_ISSUED"
}
},
"answer_version": 3
}
This request should be used for gathering certificate status information.
It initiates certificate's checks, including revocation checks, certificate chain checks and so on (if configured)
An answer will contain certificate_status object
| Parameter | Default | Mandatory | Description |
|---|---|---|---|
| cert_request | n | CertificateRequest (PKCS#10) created at step 4 (see Issue certificate ) |
|
| certificate | n | Issued and actual certificate | |
| status | y | Certificate status |
Possible certificate statuses are
- UNDEFINED
- CERT_REQUEST_INFO_CREATED
- CERT_REQUEST_CREATED
- CERT_ISSUED
- CERT_ISSUE_ERROR
- CERT_REVOKED
- CERT_EXPIRED
- INVALID
Revoke certificate
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/pki/revoke_certificate
method: PATCH
This request initiates request from PC Server to Certification Authority to revoke user's certificate
An answer contains result_only object.
Server Signer User
It can be that you will need to use server-side transactions signing (confirmation) without a mobile device.
To handle this scenarios there is feature called PC Server Signer.
It's a optional service which should be installed separately. This service works like PC Client, but on a server side. It will handle key sets for PC User, calculate digital signatures and confirm transaction on behalf of PC User, communicate with PC Server and so on.
Detailed description of PC Server Signer can be found in corresponded document.
As described there, PC Server Signer can work as owner's signer and as client's signer.
Owner's Signer API
To work as owner's signer, PC Server Signer should be configured to work directly with PC Server. It allows to
- personalize PC Server Signer automatically after PC User was created with
server_signerflag - confirm transactions automatically on behalf of Server Signer's user
Transaction confirmation will be processed as usual transaction (with all of verification steps, callbacks and so on).
If PC Server Signer and PC Server configured correctly, then you have not to make any actions to make it work.
PC Server can communicate with different PC Server Signer instances.
Server Signer Personalization
As mentioned before, if PC Server Signer and PC Server configured correctly, then you have not to make any actions to make it work.
When you will create/update a PC User with server_signer flag, PC Server will inform PC Server Signer about a new user.
By default, there is a system property in PC database, which contains PC Server Signer instance url. If you want to add new instance of PC Server Signer you should specify it in create user request like: "signer_url":"http://server-signer.loc:8080/pc-server-signer-api/personalize_async"
After this PC Server Signer will do following steps:
- request user's key set with
Export Keyrequest with random password directly fromPC Server - generate own key pair
- register public key and notification address like a mobile device with
Change Userrequest
When this process will finish, you can create transactions for this PC User.
Transaction Confirmation (Signing)
Transaction signing process is being processed in the same way.
After you have created a transaction with Push notification type, PC Server will inform PC Server Signer via PC Pusher about new transaction.
PC Server Signer, as a mobile device, will
- request transaction data from PC Server
- sign the data
- make a
Confirm Transactionrequest to PC Server
This will lead to all of verification steps, callbacks, etc.
Manual PC Server Signer actions
If by some reason you do not want to process personalization or confirmation actions automatically, then you can do this manually with PC Server Signer API.
Personalization
endpoint: {{pc-server-signer-api}}/personalize
method: POST
{
"system_id": {{system_id}},
"user_id": {{user_id}}
}
To start personalization process you should just call personalize end-point and specify system_id and user_id.
Response will contain result_only
Confirm particular transaction
endpoint: {{pc-server-signer-api}}/confirm
method: POST
{
"system_id": {{system_id}},
"user_id": {{user_id}},
"transaction_id": {{transaction_id}}
}
By calling this request, you can start confirmation (transaction signing) process for specified transactions.
PC Server Signer will get transaction data, sign them and call PC Server's confirmation end-point.
Response will contain result_only
Confirm all transactions
endpoint: {{pc-server-signer-api}}/confirm_all
method: POST
{
"system_id": {{system_id}},
"user_id": {{user_id}},
}
By calling this request you can start confirmation (transaction signing) process for all transactions for the PC User.
PC Server Signer will get transaction data, sign them and call PC Server's confirmation end-point in a loop.
Response will contain result_only
Async methods
endpoint: {{pc-server-signer-api}}/personalize_async
endpoint: {{pc-server-signer-api}}/confirm_async
endpoint: {{pc-server-signer-api}}/confirm_all_async
Those end-points will launch corresponding actions asynchronously.
Success-result will be returned rapidly without waiting action result.
Client's Signer
In this case PC Server Signer is installed on Client's side. It means that direct communication with PC Server is impossible.
PC Server Signer will work as 'big Mobile Device', it will communicate with PC External only.
Difference from Owner's side scheme is following:
- personalization process can't be done automatically, because there is no direct link with
PC Server - confirmation process can be launched manually only
- signing without a transaction is possible
Manual PC Server Signer actions
Personalization
endpoint: {{pc-server-signer-api}}/create_user
method: POST
{
"key_encryption_password": "123456",
"pc_key": {
"pc_key_version": 7,
"system_id": "f13e4375-e429-496c-ad1e-0fc3c3ecfb53",
"encrypted_key": {
"data": "pZ0nQ5Nbr/B6z27mOcw6BM4c9FOWF4cvc06/9iYcqGehey50MHDn9pLtoMhkq1VbmA5Za12CGGlDEjfztgFx7fmwC5PdYZwH",
"hmac": "HJF29VeOjifKTSGdqnsvrqSWpCDNnFzK+1eshe8DG64=",
"iv": "WJEx/En/4uE="
},
"expiration_timestamp": 1745500499,
"system_name": "Demo Portal",
"key_flags": 36639,
"kek_digits": 6,
"key_index": 1,
"pc_external_url": "https://dev.paycontrol.org/api7/pc/pc-client-api/",
"type": 1,
"system_settings": {
"confirm_code_time_sampling_interval": 180,
"auth_code_time_sampling_interval": 180
},
"user_id": "devapi7postpay-72b5656c-8b4e-48e5-8e4e-f3b51cdd8ddc",
"pc_api_version": 7,
"is_delayed": false,
"ext_auth_available_methods": [
"codeword"
]
}
}
Personalization scheme is described in detailed PC Server Signer description
To perform personalization process you should call Create User method to pc-server-signer-api url
| Parameter | Mandatory | Description |
|---|---|---|
| key_encryption_password | y | Shared secret that has been used to export key-json from PC Server. See here or here or here |
| pc_key | y | key-json that has been returned on key export (or create, or update) request |
Response is result_only object
Adding a public key
Method for adding a public key to perform signature verification
All information is taken from the "pc_key" of the PC user, whose public key will be used to verify the signature.
endpoint: {{pc-server-signer-api}}/public_key
method: POST
{
"public_key": "3066301F06082A85030701010101301306072A85030202230106082A850307010102020343000440422A52F62D4A833C3BA3DBFCEE840996F89CF83203986FCA70E6B915D27307FAAE4EC2C7A86ACADD2EFC6B11F82BDFD69BD5C1DCD1982F1537D51D4EE70BAF9F",
"system_id": "f13e4375-e429-496c-ad1e-0fc3c3ecfb53",
"user_id": "devapi7postpay-afeeeb48-f377-4045-9cce-9eef47ca84e7",
"type": 1,
"time_sampling_interval": 180
}
| Parameter | Mandatory | Description |
|---|---|---|
| public_key | y | The public key that will be used to verify the signature |
| system_id | y | Identifier of PC System of the user who owns the public key |
| user_id | y | Identifier of the PC user who owns the public key |
| type | y | Crypto type for a user's keyset. 0 - ECSDA + SHA-256 1 - GOST 34.10-2012 + GOST 34.11-2012 |
| time_sampling_interval | y | Sampling interval for signature verification |
Response is result_only object
Confirm transactions
To confirm transaction in this use case the same methods are used as for manual Owner's side case.
Signing without a Transaction
endpoint: {{pc-server-signer-api}}/sign
method: POST
Request sample
{
"transaction_data": {
"binary_data":"SGVsbG8gV29ybGQhISE=",
"text":"Money transfer to account **№213154254**, amount **$12 000**"
},
"snippet": {
"text":"account **№213154254**, amount **$12 000**",
},
"system_id": "70b5fab6-d3d1-4098-aaf9-450a496855f5",
"user_id": "rest-api-test-4d02bd9e-ac11-4661-86c5-c7c7965e6a4c"
}
Response sample
{
"answer_type": "pc_confirmation",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"pc_confirmation": {
"system_id": "70b5fab6-d3d1-4098-aaf9-450a496855f5",
"user_id": "rest-api-test-4d02bd9e-ac11-4661-86c5-c7c7965e6a4c",
"transaction_data": {
"binary_data":"SGVsbG8gV29ybGQhISE=",
"text":"Money transfer to account **№213154254**, amount **$12 000**"
},
"snippet_text": "account **№213154254**, amount **$12 000**",
"signature": "e6d48dc2411c420a15a83895e5dba7c84f670a4145f434304e1b9fb2e08af05880ba3279faabcafc66415275e435d2e4fcffee7ab55269b5990ee78ca9f6f47e",
"confirm_code": "861f99214b3c43541e3fc301784ba7877c2377dd1d0f7d212f802c4072767622",
"check_time": 1719475251,
"gost_imit": null,
"time_sampling_interval": 180
}
},
"answer_version": 3
}
This method is used to create a signed data package with PC Server Signer without creating a transaction on PC Server.
| Parameter | Mandatory | Description |
|---|---|---|
| transaction_data | y | Object with data to be confirmed (signed) |
| transaction_data .binary_data |
n | Binary data for the transaction in base64. Must be set at least one of binary_data or text |
| transaction_data .text |
n | Text for the transaction, max 10Kb length (pay attention at multi-bytes charsets). Must be set at least one of binary_data or text |
| snippet | n | Transaction snippet to show short description about data in mobile app |
| snippet .text |
y | Short transaction description to show in mobile app. If you create snippet, then snippet.text is mandatory |
| system_id | y | Identifier of PC System |
| user_id | y | PC user's identifier. |
Response contains signed data object - pc_confirmation.
Response of this call (object pc_confirmation) can be passed directly without any changes to PC Server's Check Confirmation endpoint.
In addition, receiver-side (where PC Server is installed) can use pc_confirmation object to extract signed data. E.g. pc_confirmation can be used as signed data package
Check signature
The signature verification method. It is only used to verify an asymmetric signature. The confirmation code will not be verified.
endpoint: {{pc-server-signer-api}}/validate_signature
method: POST
Request sample
{
"signature": "368fcb5597e16f8def4f6dac8ae88e8d21237ed3658d28de297a29ef474569c5b39690a16db8d4deca7fa801ce21e64e906f660b44932c119f444569fe7b5fde",
"check_time": 1722341737,
"transaction_data": {
"text": " some_text",
"binary_data": "SGVsbG8gV29ybGQhISE="
},
"snippet_text": "some_text",
"system_id": "f13e4375-e429-496c-ad1e-0fc3c3ecfb53",
"user_id": "devapi7postpay-afeeeb48-f377-4045-9cce-9eef47ca84e7"
}
Response sample Success
{
"answer_type": "result_only",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
}
},
"answer_version": 3
}
Response sample Invalid signature
{
"answer_type": "result_only",
"answer": {
"result": {
"error_message": "Invalid signature",
"error_code": 212
}
},
"answer_version": 3
}
| Parameter | Mandatory | Description |
|---|---|---|
| system_id | y | Identifier of PC System |
| user_id | y | PC user's identifier. In case of absense - method will check Independent Common Confirm Code |
| transaction_data | y | Data to be verified |
| snippet_text | n | Transaction snippet. If snippet was present in the original transaction, you need to pass same value for successfully confirmation check. |
| signature | y | Signature (asymmetric) to be verified |
| check_time | y | Unix time stamp (in seconds) in which confirmation was generated |
Events endpoint
This endpoint is used for PC Events management.
In usual cases Application does not use this endpoint. But if Application needs to register some event - it can be done.
Each PC Event contains following data:
| Parameter | Mandatory | Description |
|---|---|---|
| event_type | y | Type of the Event. Can be any string valut. For example, password_incorrect |
| event.device_event_id | n | Event identifier, generated by mobile device. Any unique string value. PC Mobile SDK uses UUID values |
| event.session_id | n | Sessing identified, generated by mobile device. Any unique string value. PC Mobile SDK uses UUID values and updates it at PC SDK initialization |
| event.device_time | n | Unix timestamp from mobile device in milliseconds |
| event.device_info | n | Information about mobile device. Any string value. PC Mobile SDK collects device info in JSON format. |
Register Event
endpoint: {{pc-server-api}}/{{system_id}}/users/{{user_id}}/events
method: POST
Request sample
{
"event_type": "password_incorrect",
"event": {
"device_event_id":"42848689-13ac-405e-95ae-2c628efe62d8",
"session_id":"7e9f60d5-0afb-43c2-8c42-2d7222d83ef0",
"device_time":1528968541746,
"device_info":"Peter's iPhone"
}
}
Request sample for
key_deletedevent
{
"event_type": "key_deleted",
"push_address":{
"device_type":"Android",
"device_push_id":"ftMhW9ApSEU:APA91bG-v-mvr_1y6MXDF91VDxmCkEnyIwkieKuf5zVY__wdUPhIZUbir5j-5UcDjb7x_YPiakLg8Ismdw55QtQxRZEy0-ufjOchPX2zUA_rx3NlCFsxJoOIawjZL2ZgwXV0DEGRz5R7"
},
"event": {
"device_event_id":"42848689-13ac-405e-95ae-2c628efe62d8",
"session_id":"7e9f60d5-0afb-43c2-8c42-2d7222d83ef0",
"device_time":1528968541746,
"device_info":"Peter's iPhone"
}
}
Response sample
{
"answer_type": "event_info",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"event_info": {
"device_event_id": "42848689-13ac-405e-95ae-2c628efe62d8",
"device_info": "Peter's iPhone",
"event_id": 4266,
"request_type": "password_incorrect",
"user_id": "rest-api-test-4d02bd9e-ac11-4661-86c5-c7c7965e6a4c",
"session_id": "7e9f60d5-0afb-43c2-8c42-2d7222d83ef0"
}
},
"answer_version": 3
}
This endpoint should be used to register any event.
In usual cases it is used by mobile app to collect events from mobile device.
key_deleted event
PC has one specialized event - key_deleted.
During processing this event PC removes push-address from user's record to avoid sending push notification to person's smartphone.
To be shure that PC removes correct push-address this request should contain push_address object with following fields:
| Parameter | Mandatory | Description |
|---|---|---|
| push_address.device_type | y | One of options listed in Device types table |
| push_address.device_push_id | y | Device push identifier from Mobile OS |
Get Event Details
endpoint: {{pc-server-api}}/events/{{event_id}}
method: GET
Request does not contain params
Response sample
{
"answer_type": "event_info",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"event_info": {
"request_type": "change_user",
"system_id": "f41c7f8e-a655-4540-9cac-f499468329da",
"pc_instance_name": "pcs-node-1",
"created_at": 1652795952858,
"event_data": "{\"current\":{\"public_key\":\"3059301306072a8648ce3d020106082a8648ce3d030107034200042ef111f3be77c74abeac08c87c9ee27a56ae53bc546d4e15fb9ff9f372a98794bcc7e95c538035fc3bb0d9c1ba0e46ca5fa394425a400793c3888e7c375dda5e\",\"user_name\":\"Modified User Name\",\"push_address\":{\"device_push_id\":\"ftMhW9ApSEU:APA91bG-v-mvr_1y6MXDF91VDxmCkEnyIwkieKuf5zVY__wdUPhIZUbir5j-5UcDjb7x_YPiakLg8Ismdw55QtQxRZEy0-ufjOchPX2zUA_rx3NlCFsxJoOIawjZL2ZgwXV0DEGRz5R7\",\"device_type\":\"Android\",\"app_id\":\"org.paycontrol.app\"}},\"previous\":{\"public_key\":\"\",\"user_name\":\"\"}}",
"request_url": "http://dev.paycontrol.org/pc-api/f41c7f8e-a655-4540-9cac-f499468329da/users/devapi5postpay-cf86ef01-04d4-42d6-b7fd-b31c01c06e1d",
"requester_ip_address": "192.168.88.117, 192.168.88.52",
"request_result": 0,
"pc_version": {
"pc_version": "99-app_extra.272-pgsql",
"product": "PC Server",
"pc_api_version": 5
},
"event_id": 1857,
"updated_at": 1652795952938,
"user_id": "devapi5postpay-cf86ef01-04d4-42d6-b7fd-b31c01c06e1d",
"connection_info": {
"dst": {
"port": "8080",
"ip": "172.30.0.2",
"mac": ""
},
"src": {
"port": "55496",
"ip": "172.30.0.7",
"mac": "02-42-AC-1E-00-02"
}
}
}
},
"answer_version": 3
}
This request should be used to get event details
Get events
endpoint: {{pc-server-api}}/events/
method: POST
Request sample
{
"system_id": "e55d3d79-327e-4c23-b152-967a57258d57",
"user_id": "efa59ce9-9b10-48b5-8fcf-bf25c4267214",
"is_cleaned": false,
"date_from": "2020-07-06 22:12:22.0 +0000",
"date_to": "2021-07-06 22:12:22.0 +0000"
}
Response sample
{
"answer_type": "events",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"events": {
"events_to_post_list": [
{
"request_type": "change_user",
"system_id": "f41c7f8e-a655-4540-9cac-f499468329da",
"pc_instance_name": "pcs-node-1",
"created_at": 1652795952858,
"event_data": "{\"current\":{\"public_key\":\"3059301306072a8648ce3d020106082a8648ce3d030107034200042ef111f3be77c74abeac08c87c9ee27a56ae53bc546d4e15fb9ff9f372a98794bcc7e95c538035fc3bb0d9c1ba0e46ca5fa394425a400793c3888e7c375dda5e\",\"user_name\":\"Modified User Name\",\"push_address\":{\"device_push_id\":\"ftMhW9ApSEU:APA91bG-v-mvr_1y6MXDF91VDxmCkEnyIwkieKuf5zVY__wdUPhIZUbir5j-5UcDjb7x_YPiakLg8Ismdw55QtQxRZEy0-ufjOchPX2zUA_rx3NlCFsxJoOIawjZL2ZgwXV0DEGRz5R7\",\"device_type\":\"Android\",\"app_id\":\"org.paycontrol.app\"}},\"previous\":{\"public_key\":\"\",\"user_name\":\"\"}}",
"request_url": "http://dev.paycontrol.org/pc-api/f41c7f8e-a655-4540-9cac-f499468329da/users/devapi5postpay-cf86ef01-04d4-42d6-b7fd-b31c01c06e1d",
"requester_ip_address": "192.168.88.117, 192.168.88.52",
"request_result": 0,
"pc_version": {
"pc_version": "5.4.272-pgsql",
"product": "PC Server",
"pc_api_version": 5
},
"event_id": 1857,
"updated_at": 1652795952938,
"user_id": "devapi5postpay-cf86ef01-04d4-42d6-b7fd-b31c01c06e1d",
"connection_info": {
"dst": {
"port": "8080",
"ip": "172.30.0.2",
"mac": ""
},
"src": {
"port": "55496",
"ip": "172.30.0.7",
"mac": "02-42-AC-1E-00-02"
}
}
},
{
"pc_version": {
"pc_version": "5.4.272-pgsql",
"product": "PC Server",
"pc_api_version": 5
},
"event_id": 1840,
"request_type": "create_operation",
"user_id": "devapi5postpay-cf86ef01-04d4-42d6-b7fd-b31c01c06e1d",
"connection_info": {
"dst": {
"port": "8080",
"ip": "172.30.0.2",
"mac": ""
},
"src": {
"port": "50422",
"ip": "172.30.0.7",
"mac": "02-42-AC-1E-00-02"
}
},
"system_id": "f41c7f8e-a655-4540-9cac-f499468329da",
"pc_instance_name": "pcs-node-1",
"created_at": 1652786366866,
"operation_id": "90fe77c4-13ec-4043-98af-20896530ae26",
"request_url": "http://dev.paycontrol.org/pc-api/f41c7f8e-a655-4540-9cac-f499468329da/users/devapi5postpay-cf86ef01-04d4-42d6-b7fd-b31c01c06e1d/operations/90fe77c4-13ec-4043-98af-20896530ae26",
"requester_ip_address": "192.168.88.117, 192.168.88.52",
"request_result": 0
},
{
"pc_version": {
"pc_version": "5.4.272-pgsql",
"product": "PC Server",
"pc_api_version": 5
},
"event_id": 1839,
"request_type": "create_operation",
"user_id": "devapi5postpay-cf86ef01-04d4-42d6-b7fd-b31c01c06e1d",
"connection_info": {
"dst": {
"port": "8080",
"ip": "172.30.0.2",
"mac": ""
},
"src": {
"port": "50232",
"ip": "172.30.0.7",
"mac": "02-42-AC-1E-00-02"
}
},
"system_id": "f41c7f8e-a655-4540-9cac-f499468329da",
"pc_instance_name": "pcs-node-1",
"created_at": 1652786315167,
"request_url": "http://dev.paycontrol.org/pc-api/f41c7f8e-a655-4540-9cac-f499468329da/users/devapi5postpay-cf86ef01-04d4-42d6-b7fd-b31c01c06e1d/operations",
"requester_ip_address": "192.168.88.23, 192.168.88.52",
"request_result": 0
}
],
"total_count": 3,
"from": 0,
"to": 3
}
},
"answer_version": 3
}
This endpoint is used for fetching array of events with filter opportunity in request and simple pagination
Filter options:
| Parameter | Mandatory | Type | Description |
|---|---|---|---|
| system_id | no | String | system_id |
| user_id | no | String | user_id |
| transaction_id | no | String | transaction_id |
| operation_id | no | String | operation_id |
| pc_instance_name | no | String | see |
| session_id | no | String | see |
| request_type | no | String | type of request see |
| request_result | no | String | result of the request see |
| requester_ip | no | String | IP address of the requester see |
| is_cleaned | no | boolean | if we look for already cleaned events or no (true/false) |
| date_from | no | String (yyyy-MM-dd HH:mm:ss.S Z) | search start date |
| date_to | no | String (yyyy-MM-dd HH:mm:ss.S Z) | end date of search |
| from | no | integer | get results from position |
Clean events
endpoint: {{pc-server-api}}/events/
method: DELETE
Request sample
{
"user_id": "local-0254a69d-5d2d-4b87-a1d5-0da7e8410524",
"date_from": "2021-08-13 15:26:00.0 +0000",
"date_to": "2021-08-13 16:06:22.0 +0000"
}
Response sample
{
"answer_type": "cleaned_events",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"cleaned_events": {
"events_to_post_list": [
{
"transaction_id": "792fc97d-f268-48cc-8842-2be00ee956b9",
"pc_version": {
"pc_version": "5.2",
"product": "PC Server",
"pc_api_version": 4
},
"event_id": 4782,
"request_type": "get_transaction_data",
"connection_info": {},
"user_id": "local-0254a69d-5d2d-4b87-a1d5-0da7e8410524",
"system_id": "4cad6f8c-59dd-4248-a7e2-00a5470eff59",
"created_at": 1628868464022,
"request_url": "http://192.168.89.124:8080/pc-api/4cad6f8c-59dd-4248-a7e2-00a5470eff59/users/local-0254a69d-5d2d-4b87-a1d5-0da7e8410524/transactions/792fc97d-f268-48cc-8842-2be00ee956b9/get_data",
"requester_ip_address": "192.168.89.124",
"request_result": 0
},
{
"pc_version": {
"pc_version": "5.2",
"product": "PC Server",
"pc_api_version": 4
},
"event_id": 4781,
"request_type": "create_transaction",
"connection_info": {},
"user_id": "local-0254a69d-5d2d-4b87-a1d5-0da7e8410524",
"system_id": "4cad6f8c-59dd-4248-a7e2-00a5470eff59",
"created_at": 1628868447785,
"request_url": "http://192.168.89.124:8080/pc-api/4cad6f8c-59dd-4248-a7e2-00a5470eff59/users/local-0254a69d-5d2d-4b87-a1d5-0da7e8410524/transactions",
"requester_ip_address": "192.168.89.124",
"request_result": 0
}
],
"total_count": 2,
"from": 0,
"to": 2
}
},
"answer_version": 3
}
This endpoint is used for clean big size events fields like device_info, event_data, connection_info for selected events by filtering in request and simple pagination
Filter options:
| Parameter | Mandatory | Type | Description |
|---|---|---|---|
| system_id | no | String | system_id |
| user_id | no | String | user_id |
| request_type | no | String | type of request see |
| request_result | no | String | result of the request see |
| requester_ip | no | String | IP address of the requester see |
| date_from | no | String (yyyy-MM-dd HH:mm:ss.S Z) | search start date |
| date_to | no | String (yyyy-MM-dd HH:mm:ss.S Z) | end date of search |
| from | no | integer | get results from position |
Pagination
Pagination parameters in server response:
{
"total_count": 2,
"from": 1,
"to": 2
}
Each request get events or clean events returns array of events. Maximum size of this array is limited by 200 elements. Each response has a pagination parameters as follows:
| Parameter | Type | Description |
|---|---|---|
| total_count | integer | total count of events for request with applied filter |
| from | integer | starting position of server's response |
| to | integer | finishing position of server's response |
Conflicts resolving endpoint
This endpoint is used to verify signatures generated by PC and get detailed information about PC users
Check Confirmation
endpoint: {{pc-server-api}}/rks/check_confirmation
method: POST
Request sample
{
"system_id":"{{system_id}}",
"user_id":"{{user_id}}",
"transaction_data":{
"binary_data":"SGVsbG8gV29ybGQhISE=",
"text":"Money transfer to account №213154254, amount $12 000"
},
"snippet_text": "Transfer - $12 000",
"confirm_code":"936A185CAAA266BB9CBE981E9E05CB78CD732B0B3280EB944412BB6F8F8F07AF",
"signature":"3045022100ffb3e2661bfa7f6821435a48924ee4019531a5beb7f46e23ce8924b5a84d8167022052ca4cefd5fc6b66837419aee0483b9bc10fd5113b92b6082b7be0f9c21c7461",
"gost_imit": "3e4b879d799cad9d9866cca9a3b949e015b5f6430cabe8eb3df878102a49b2d1",
"check_time":1541600083
}
Response sample
{
"answer_type": "check_confirmation_result",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"check_confirmation_result": {
"check_error_message": "Signature is invalid",
"key_id": 131,
"tlv_data": "11000000aec390c29fc390c2b5c391c280c390c2b5c390c2b2c390c2bec390c2b420c391c281c391c280c390c2b5c390c2b4c391c281c391c282c390c2b220c390c2bdc390c2b020c391c281c391c287c391c291c391c28220c3a2c284c29632313331353432353420c390c2bdc390c2b020c391c281c391c283c390c2bcc390c2bcc391c28320313230303020c391c280c391c283c390c2b1c390c2bbc390c2b5c390c2b948656c6c6f20576f726c642121211200000032726573742d6170692d746573742d34643032626439652d616331312d343636312d383663352d633763373936356536613463140000000383b6ed",
"publickey_id": 88,
"check_error_code": 278
}
},
"answer_version": 3
}
This endpoint should be used to check signature and/or confirmation code generated by PC.
Signature and/or confirmation code with timestamp will be returned to Application in transaction callback (see Transaction endpoint description) and should be stored by Application with transaction data as digital signature.
If someone wants to check this signature then he can do this with this endpoint.
Request params:
| Parameter | Mandatory | Description |
|---|---|---|
| system_id | y | Identifier of PC System |
| user_id | n | PC user's identifier. In case of absense - method will check Independent Common Confirm Code |
| transaction_data | y | Data to be verified |
| snippet_text | n | Transaction snippet. If snippet was present in the original transaction, you need to pass same value for successfully confirmation check. |
| confirm_code | y | Confirmation code (symmetric) to be verified |
| signature | n | Signature (asymmetric) to be verified |
| gost_imit | n | Server-side HMAC (imit) value |
| check_time | y | Unix time stamp (in seconds) in which confirmation was generated |
| time_sampling_interval | n | Period of validity of Confirm Code in case of checking Independent Common Confirm Code or Independent Confirm Code without Transaction |
Response contains result object and check_confirmation_result object with following fields:
| Parameter | Description |
|---|---|
| check_error_code | Error code generated during checking |
| check_error_message | Error message generated during checking |
| key_id | User's key (symmetric) identifier used to check confirmation code |
| publickey_id | User's public key (asymmetric) identifier used to check confirmation code |
| tlv_data | Binary data in hex-format used as input for cryptographic algorithms. Generated by PC rules from transaction data, time, device fingerprint, user identifier and so on. |
Check CMS Signature
endpoint: {{pc-server-api}}/rks/check_cms
method: POST
Request sample
{
"system_id":"{{system_id}}",
"user_id":"{{user_id}}",
"transaction_data":{
"binary_data":"SGVsbG8gV29ybGQhISE=",
"text":"Money transfer to account №213154254, amount $12 000"
},
"cms_signature":"MIIGlgYJKoZIhvcNAQcCoIIGhzCCBoMCAQExDTALBglghkgBZQMEAgEwCwYJKoZIhvcNAQcBoIIEiDCCBIQwggJsoAMCAQICAhAhMA0GCSqGSIb3DQEBCwUAMHoxCzAJBgNVBAYTAlJVMQ8wDQYDVQQIDAZNb3Njb3cxFjAUBgNVBAoMDVNhZmVUZWNoIEx0ZC4xIDAeBgNVBAMMF09wZW5TU0wgSW50ZXJtZWRpYXRlIENBMSAwHgYJKoZIhvcNAQkBFhF0ZWNoQHNhZmUtdGVjaC5ydTAeFw0yMDA4MTMxMjUzMDlaFw0yMTA4MjMxMjUzMDlaMFoxCzAJBgNVBAYTAlNHMRIwEAYDVQQIDAlTaW5nYXBvcmUxEjAQBgNVBAcMCVNpbmdhcG9yZTEPMA0GA1UECgwGQWlyb21lMRIwEAYDVQQDDAlUZXN0IFVzZXIwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQWqMiUTQcKhNaReblx54iObGzcpmwffvl2+d3iJ8V7uf6\/wpTvVMTuHRtBshucwwZ1kHvE7Y4Bv6aDU57u9lqjo4H+MIH7MAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFKrDj1wRe681Yn6ud4yZETQWgySLMB8GA1UdIwQYMBaAFEkMJKbw+43P5sCbeS4LwzcklEkYMA4GA1UdDwEB\/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0cDovL3BjLWRldmVsb3AvY3JsL2ludGVybWVkaWF0ZS5jcmwwDQYJKoZIhvcNAQELBQADggIBAFGns0L29m45lBtc2XBBz3zV7zloQqLCuJ0oCDRPv0D+7QLxyaIOCMAeNiQxdsxN811RsSzPQ+P5YOGmlYELcAX2yegfW2YblOcPwmyG1Ktlo0Jc8ezCPydxiQsmYSvYs1zHpmONoNvfVqf4uZbDnNrbF6FNTQeK5KAqu2rWdiOeBo\/1Yjcse3bcVqKhmf+9j8brCqR6lE1AZoakFLqiKShStj5zxJCvhWIcfUDf31g43gSnIi6q6fXzqRqX4kjtbAY9vfLTpbpmT5MSX2M7hNfnbQQmXrVtPwWFr\/EmXfYq5uCmFe00EZDaenCjGqKzEmT07ME58wspp6MiVwk6yteCsOOMcOPGM\/sf3Af6GAPOSkHH2GUSRWNA1Ri9HTSCfyI0WiMX4VRApDRrr+MKWKCViZb27rouYWzj9h+mT6YrDHHdQ+cW9VJq2b1wIZACy8MmU7c87VTnjW+cv96Ij8aVE4YgOHjfrsYnTNvKqQwZS6I0uFZCXtx51Ti5MUGYKwgUvatFs8D0wSyZVE1zPP\/9rFU9cAac8LbXyW7v3htL5CSr69aTBI392ZnVxBNfm3RzDUxzvBdfgHjra0gJNp6K0iFBAGtCGgcywXd\/fZ8CL0lDLVZBGYIjEQcbbyhWxyfrM2A6OXftMjig0Iyr9qZ7NgR\/whu\/LoH6rKAmNODRMYIB1DCCAdACAQEwgYAwejELMAkGA1UEBhMCUlUxDzANBgNVBAgMBk1vc2NvdzEWMBQGA1UECgwNU2FmZVRlY2ggTHRkLjEgMB4GA1UEAwwXT3BlblNTTCBJbnRlcm1lZGlhdGUgQ0ExIDAeBgkqhkiG9w0BCQEWEXRlY2hAc2FmZS10ZWNoLnJ1AgIQITALBglghkgBZQMEAgGggeQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODEzMTQ0NjM5WjAvBgkqhkiG9w0BCQQxIgQg2yLkZUSO3OHM\/1FXLzcChk\/fCj5Yww\/59bWUC4WEPmcweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDAYIKoZIzj0EAwIFAARGMEQCIHwrB8ZbLllIIcMUk\/tc\/dBdk2Y0DxJaIs\/KNxhEKH1xAiBs28XsyyFfRg\/rlr03KiAYHMYDihNqiSKlfcwsNnywvw=="
}
Response sample
{
"answer_type": "check_cms_result",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"check_cms_result": {
"check_error_message": "Success",
"certificates": [
{
"public_key": {
"publickeyid": 13,
"public_key": "3059301306072a8648ce3d020106082a8648ce3d0301070342000416a8c8944d070a84d69179b971e7888e6c6cdca66c1f7ef976f9dde227c57bb9febfc294ef54c4ee1d1b41b21b9cc30675907bc4ed8e01bfa683539eeef65aa3",
"eventid": 188,
"is_deleted": 0,
"created_at": "2020-05-29 22:57:06.803 +0300",
"keyid": 9
},
"cms_certificate": "MIIEhDCCAmygAwIBAgICECEwDQYJKoZIhvcNAQELBQAwejELMAkGA1UEBhMCUlUxDzANBgNVBAgMBk1vc2NvdzEWMBQGA1UECgwNU2FmZVRlY2ggTHRkLjEgMB4GA1UEAwwXT3BlblNTTCBJbnRlcm1lZGlhdGUgQ0ExIDAeBgkqhkiG9w0BCQEWEXRlY2hAc2FmZS10ZWNoLnJ1MB4XDTIwMDgxMzEyNTMwOVoXDTIxMDgyMzEyNTMwOVowWjELMAkGA1UEBhMCU0cxEjAQBgNVBAgMCVNpbmdhcG9yZTESMBAGA1UEBwwJU2luZ2Fwb3JlMQ8wDQYDVQQKDAZBaXJvbWUxEjAQBgNVBAMMCVRlc3QgVXNlcjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABBaoyJRNBwqE1pF5uXHniI5sbNymbB9++Xb53eInxXu5/r/ClO9UxO4dG0GyG5zDBnWQe8TtjgG/poNTnu72WqOjgf4wgfswCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwMwYJYIZIAYb4QgENBCYWJE9wZW5TU0wgR2VuZXJhdGVkIENsaWVudCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUqsOPXBF7rzVifq53jJkRNBaDJIswHwYDVR0jBBgwFoAUSQwkpvD7jc/mwJt5LgvDNySUSRgwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDA3BgNVHR8EMDAuMCygKqAohiZodHRwOi8vcGMtZGV2ZWxvcC9jcmwvaW50ZXJtZWRpYXRlLmNybDANBgkqhkiG9w0BAQsFAAOCAgEAUaezQvb2bjmUG1zZcEHPfNXvOWhCosK4nSgINE+/QP7tAvHJog4IwB42JDF2zE3zXVGxLM9D4/lg4aaVgQtwBfbJ6B9bZhuU5w/CbIbUq2WjQlzx7MI/J3GJCyZhK9izXMemY42g299Wp/i5lsOc2tsXoU1NB4rkoCq7atZ2I54Gj/ViNyx7dtxWoqGZ/72PxusKpHqUTUBmhqQUuqIpKFK2PnPEkK+FYhx9QN/fWDjeBKciLqrp9fOpGpfiSO1sBj298tOlumZPkxJfYzuE1+dtBCZetW0/BYWv8SZd9irm4KYV7TQRkNp6cKMaorMSZPTswTnzCymnoyJXCTrK14Kw44xw48Yz+x/cB/oYA85KQcfYZRJFY0DVGL0dNIJ/IjRaIxfhVECkNGuv4wpYoJWJlvbuui5hbOP2H6ZPpisMcd1D5xb1UmrZvXAhkALLwyZTtzztVOeNb5y/3oiPxpUThiA4eN+uxidM28qpDBlLojS4VkJe3HnVOLkxQZgrCBS9q0WzwPTBLJlUTXM8//2sVT1wBpzwttfJbu/eG0vkJKvr1pMEjf3ZmdXEE1+bdHMNTHO8F1+AeOtrSAk2norSIUEAa0IaBzLBd399nwIvSUMtVkEZgiMRBxtvKFbHJ+szYDo5d+0yOKDQjKv2pns2BH/CG78ugfqsoCY04NE=",
"user_certificate": {
"certrequest": "MIIBETCBugIBADBaMQswCQYDVQQGEwJTRzESMBAGA1UECAwJU2luZ2Fwb3JlMRIwEAYDVQQHDAlTaW5nYXBvcmUxDzANBgNVBAoMBkFpcm9tZTESMBAGA1UEAwwJVGVzdCBVc2VyMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEFqjIlE0HCoTWkXm5ceeIjmxs3KZsH375dvnd4ifFe7n+v8KU71TE7h0bQbIbnMMGdZB7xO2OAb+mg1Oe7vZaozAKBggqhkjOPQQDAgNGADBDAh9GsJ9/EYGoLQ24Z6lYuMNWXH3X+T+ACeK/rfpqI6+kAiAWeZatHpVBMlJTA79Kyu8qHQcCzywqvwECGZIMiTCkFA==",
"publickeyid": 13,
"certrequestinfo": "MIG6AgEAMFoxCzAJBgNVBAYTAlNHMRIwEAYDVQQIDAlTaW5nYXBvcmUxEjAQBgNVBAcMCVNpbmdhcG9yZTEPMA0GA1UECgwGQWlyb21lMRIwEAYDVQQDDAlUZXN0IFVzZXIwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQWqMiUTQcKhNaReblx54iObGzcpmwffvl2+d3iJ8V7uf6/wpTvVMTuHRtBshucwwZ1kHvE7Y4Bv6aDU57u9lqj",
"is_deleted": 0,
"updated_at": "2020-08-13 15:53:09.714 +0300",
"certificateid": 33,
"certificate": "MIIEhDCCAmygAwIBAgICECEwDQYJKoZIhvcNAQELBQAwejELMAkGA1UEBhMCUlUxDzANBgNVBAgMBk1vc2NvdzEWMBQGA1UECgwNU2FmZVRlY2ggTHRkLjEgMB4GA1UEAwwXT3BlblNTTCBJbnRlcm1lZGlhdGUgQ0ExIDAeBgkqhkiG9w0BCQEWEXRlY2hAc2FmZS10ZWNoLnJ1MB4XDTIwMDgxMzEyNTMwOVoXDTIxMDgyMzEyNTMwOVowWjELMAkGA1UEBhMCU0cxEjAQBgNVBAgMCVNpbmdhcG9yZTESMBAGA1UEBwwJU2luZ2Fwb3JlMQ8wDQYDVQQKDAZBaXJvbWUxEjAQBgNVBAMMCVRlc3QgVXNlcjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABBaoyJRNBwqE1pF5uXHniI5sbNymbB9++Xb53eInxXu5/r/ClO9UxO4dG0GyG5zDBnWQe8TtjgG/poNTnu72WqOjgf4wgfswCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwMwYJYIZIAYb4QgENBCYWJE9wZW5TU0wgR2VuZXJhdGVkIENsaWVudCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUqsOPXBF7rzVifq53jJkRNBaDJIswHwYDVR0jBBgwFoAUSQwkpvD7jc/mwJt5LgvDNySUSRgwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDA3BgNVHR8EMDAuMCygKqAohiZodHRwOi8vcGMtZGV2ZWxvcC9jcmwvaW50ZXJtZWRpYXRlLmNybDANBgkqhkiG9w0BAQsFAAOCAgEAUaezQvb2bjmUG1zZcEHPfNXvOWhCosK4nSgINE+/QP7tAvHJog4IwB42JDF2zE3zXVGxLM9D4/lg4aaVgQtwBfbJ6B9bZhuU5w/CbIbUq2WjQlzx7MI/J3GJCyZhK9izXMemY42g299Wp/i5lsOc2tsXoU1NB4rkoCq7atZ2I54Gj/ViNyx7dtxWoqGZ/72PxusKpHqUTUBmhqQUuqIpKFK2PnPEkK+FYhx9QN/fWDjeBKciLqrp9fOpGpfiSO1sBj298tOlumZPkxJfYzuE1+dtBCZetW0/BYWv8SZd9irm4KYV7TQRkNp6cKMaorMSZPTswTnzCymnoyJXCTrK14Kw44xw48Yz+x/cB/oYA85KQcfYZRJFY0DVGL0dNIJ/IjRaIxfhVECkNGuv4wpYoJWJlvbuui5hbOP2H6ZPpisMcd1D5xb1UmrZvXAhkALLwyZTtzztVOeNb5y/3oiPxpUThiA4eN+uxidM28qpDBlLojS4VkJe3HnVOLkxQZgrCBS9q0WzwPTBLJlUTXM8//2sVT1wBpzwttfJbu/eG0vkJKvr1pMEjf3ZmdXEE1+bdHMNTHO8F1+AeOtrSAk2norSIUEAa0IaBzLBd399nwIvSUMtVkEZgiMRBxtvKFbHJ+szYDo5d+0yOKDQjKv2pns2BH/CG78ugfqsoCY04NE=",
"created_at": "2020-08-13 15:41:01.310 +0300",
"ca_extra": {
"privyId": "123456",
"privyId_enrollmentCode": "123456",
"privyId_merchantKey": "123456"
},
"transactionid": "06a2a194-d1ad-4de0-a877-4f5d77a6b31d",
"status": 3
},
"key_info": {
"eventid": 0,
"is_deleted": 0,
"key_content": "750230565d54755b3d2c160411216a5d6b796b59681441456a2e21727b1a0736606532406a16181d706408052076410b22001b53251f5c3c395d7657530e3c37",
"key_flags": 2048,
"keyid": 9,
"created_at": "2020-05-28 17:33:19.578 +0300",
"user_key_version": 1,
"expiration_date": "2021-05-28 17:33:19.577 +0300",
"userid": "rest-api-test-926c3ecf-a683-4510-be0d-d1d9d40ddead"
},
"cms_created_at": "2020-08-13 17:46:39.0 +0300"
}
],
"check_error_code": 0
}
},
"answer_version": 3
}
This endpoint should be used to check CMS digital signature, generated by PC with user's certificate.
CMS signature MUST contain signed attribute with OID 1.2.840.113549.1.9.5 (signing-time) to identify PC user's details for exact moment.
If someone wants to check this signature then he can do this with this endpoint.
Request params:
| Parameter | Mandatory | Description |
|---|---|---|
| system_id | y | Identifier of PC System |
| user_id | y | PC user's identifier |
| transaction_data | y | data to be verified |
| cms_signature | y | CMS digital signature (hex-representation) |
Response contains result object and check_cms_result object with following fields:
| Parameter | Description |
|---|---|
| check_error_code | Error code generated during checking |
| check_error_message | Error message generated during checking |
| certificates | Set of CMS signer's certificates with information about PC user, corresponded with those certificate and signing-time |
During CMS verification PC Server proceeds following steps:
- Extract set of SignerInfos
- For each SignerInfo
- verifies signature with signer's certificate
- extract signing-time
- find user's data, which was actual for signing-time
- find user's certificate, which was actual for signing-time
- compare certificate in CMS SignerInfo with user's certificate in PC database
- Build a response
Check Signed PDF
endpoint: {{pc-server-api}}/rks/check_pdf
method: POST
Request sample
{
"system_id":"{{system_id}}",
"user_id":"{{user_id}}",
"transaction_data":{
"binary_data":"[signed-pdf-base64-encoded]",
}
}
Response sample
{
"answer_type": "check_pdf_result",
"answer": {
"result": {
"error_message": "Success",
"error_code": 0
},
"check_pdf_result": {
"check_error_message": "Success",
"certificates": [
{
"public_key": {
"publickeyid": 13,
"public_key": "3059301306072a8648ce3d020106082a8648ce3d0301070342000416a8c8944d070a84d69179b971e7888e6c6cdca66c1f7ef976f9dde227c57bb9febfc294ef54c4ee1d1b41b21b9cc30675907bc4ed8e01bfa683539eeef65aa3",
"eventid": 188,
"is_deleted": 0,
"created_at": "2020-05-29 22:57:06.803 +0300",
"keyid": 9
},
"cms_certificate": "MIIEhDCCAmygAwIBAgICECEwDQYJKoZIhvcNAQELBQAwejELMAkGA1UEBhMCUlUxDzANBgNVBAgMBk1vc2NvdzEWMBQGA1UECgwNU2FmZVRlY2ggTHRkLjEgMB4GA1UEAwwXT3BlblNTTCBJbnRlcm1lZGlhdGUgQ0ExIDAeBgkqhkiG9w0BCQEWEXRlY2hAc2FmZS10ZWNoLnJ1MB4XDTIwMDgxMzEyNTMwOVoXDTIxMDgyMzEyNTMwOVowWjELMAkGA1UEBhMCU0cxEjAQBgNVBAgMCVNpbmdhcG9yZTESMBAGA1UEBwwJU2luZ2Fwb3JlMQ8wDQYDVQQKDAZBaXJvbWUxEjAQBgNVBAMMCVRlc3QgVXNlcjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABBaoyJRNBwqE1pF5uXHniI5sbNymbB9++Xb53eInxXu5/r/ClO9UxO4dG0GyG5zDBnWQe8TtjgG/poNTnu72WqOjgf4wgfswCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwMwYJYIZIAYb4QgENBCYWJE9wZW5TU0wgR2VuZXJhdGVkIENsaWVudCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUqsOPXBF7rzVifq53jJkRNBaDJIswHwYDVR0jBBgwFoAUSQwkpvD7jc/mwJt5LgvDNySUSRgwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDA3BgNVHR8EMDAuMCygKqAohiZodHRwOi8vcGMtZGV2ZWxvcC9jcmwvaW50ZXJtZWRpYXRlLmNybDANBgkqhkiG9w0BAQsFAAOCAgEAUaezQvb2bjmUG1zZcEHPfNXvOWhCosK4nSgINE+/QP7tAvHJog4IwB42JDF2zE3zXVGxLM9D4/lg4aaVgQtwBfbJ6B9bZhuU5w/CbIbUq2WjQlzx7MI/J3GJCyZhK9izXMemY42g299Wp/i5lsOc2tsXoU1NB4rkoCq7atZ2I54Gj/ViNyx7dtxWoqGZ/72PxusKpHqUTUBmhqQUuqIpKFK2PnPEkK+FYhx9QN/fWDjeBKciLqrp9fOpGpfiSO1sBj298tOlumZPkxJfYzuE1+dtBCZetW0/BYWv8SZd9irm4KYV7TQRkNp6cKMaorMSZPTswTnzCymnoyJXCTrK14Kw44xw48Yz+x/cB/oYA85KQcfYZRJFY0DVGL0dNIJ/IjRaIxfhVECkNGuv4wpYoJWJlvbuui5hbOP2H6ZPpisMcd1D5xb1UmrZvXAhkALLwyZTtzztVOeNb5y/3oiPxpUThiA4eN+uxidM28qpDBlLojS4VkJe3HnVOLkxQZgrCBS9q0WzwPTBLJlUTXM8//2sVT1wBpzwttfJbu/eG0vkJKvr1pMEjf3ZmdXEE1+bdHMNTHO8F1+AeOtrSAk2norSIUEAa0IaBzLBd399nwIvSUMtVkEZgiMRBxtvKFbHJ+szYDo5d+0yOKDQjKv2pns2BH/CG78ugfqsoCY04NE=",
"user_certificate": {
"certrequest": "MIIBETCBugIBADBaMQswCQYDVQQGEwJTRzESMBAGA1UECAwJU2luZ2Fwb3JlMRIwEAYDVQQHDAlTaW5nYXBvcmUxDzANBgNVBAoMBkFpcm9tZTESMBAGA1UEAwwJVGVzdCBVc2VyMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEFqjIlE0HCoTWkXm5ceeIjmxs3KZsH375dvnd4ifFe7n+v8KU71TE7h0bQbIbnMMGdZB7xO2OAb+mg1Oe7vZaozAKBggqhkjOPQQDAgNGADBDAh9GsJ9/EYGoLQ24Z6lYuMNWXH3X+T+ACeK/rfpqI6+kAiAWeZatHpVBMlJTA79Kyu8qHQcCzywqvwECGZIMiTCkFA==",
"publickeyid": 13,
"certrequestinfo": "MIG6AgEAMFoxCzAJBgNVBAYTAlNHMRIwEAYDVQQIDAlTaW5nYXBvcmUxEjAQBgNVBAcMCVNpbmdhcG9yZTEPMA0GA1UECgwGQWlyb21lMRIwEAYDVQQDDAlUZXN0IFVzZXIwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQWqMiUTQcKhNaReblx54iObGzcpmwffvl2+d3iJ8V7uf6/wpTvVMTuHRtBshucwwZ1kHvE7Y4Bv6aDU57u9lqj",
"is_deleted": 0,
"updated_at": "2020-08-13 15:53:09.714 +0300",
"certificateid": 33,
"certificate": "MIIEhDCCAmygAwIBAgICECEwDQYJKoZIhvcNAQELBQAwejELMAkGA1UEBhMCUlUxDzANBgNVBAgMBk1vc2NvdzEWMBQGA1UECgwNU2FmZVRlY2ggTHRkLjEgMB4GA1UEAwwXT3BlblNTTCBJbnRlcm1lZGlhdGUgQ0ExIDAeBgkqhkiG9w0BCQEWEXRlY2hAc2FmZS10ZWNoLnJ1MB4XDTIwMDgxMzEyNTMwOVoXDTIxMDgyMzEyNTMwOVowWjELMAkGA1UEBhMCU0cxEjAQBgNVBAgMCVNpbmdhcG9yZTESMBAGA1UEBwwJU2luZ2Fwb3JlMQ8wDQYDVQQKDAZBaXJvbWUxEjAQBgNVBAMMCVRlc3QgVXNlcjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABBaoyJRNBwqE1pF5uXHniI5sbNymbB9++Xb53eInxXu5/r/ClO9UxO4dG0GyG5zDBnWQe8TtjgG/poNTnu72WqOjgf4wgfswCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwMwYJYIZIAYb4QgENBCYWJE9wZW5TU0wgR2VuZXJhdGVkIENsaWVudCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUqsOPXBF7rzVifq53jJkRNBaDJIswHwYDVR0jBBgwFoAUSQwkpvD7jc/mwJt5LgvDNySUSRgwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDA3BgNVHR8EMDAuMCygKqAohiZodHRwOi8vcGMtZGV2ZWxvcC9jcmwvaW50ZXJtZWRpYXRlLmNybDANBgkqhkiG9w0BAQsFAAOCAgEAUaezQvb2bjmUG1zZcEHPfNXvOWhCosK4nSgINE+/QP7tAvHJog4IwB42JDF2zE3zXVGxLM9D4/lg4aaVgQtwBfbJ6B9bZhuU5w/CbIbUq2WjQlzx7MI/J3GJCyZhK9izXMemY42g299Wp/i5lsOc2tsXoU1NB4rkoCq7atZ2I54Gj/ViNyx7dtxWoqGZ/72PxusKpHqUTUBmhqQUuqIpKFK2PnPEkK+FYhx9QN/fWDjeBKciLqrp9fOpGpfiSO1sBj298tOlumZPkxJfYzuE1+dtBCZetW0/BYWv8SZd9irm4KYV7TQRkNp6cKMaorMSZPTswTnzCymnoyJXCTrK14Kw44xw48Yz+x/cB/oYA85KQcfYZRJFY0DVGL0dNIJ/IjRaIxfhVECkNGuv4wpYoJWJlvbuui5hbOP2H6ZPpisMcd1D5xb1UmrZvXAhkALLwyZTtzztVOeNb5y/3oiPxpUThiA4eN+uxidM28qpDBlLojS4VkJe3HnVOLkxQZgrCBS9q0WzwPTBLJlUTXM8//2sVT1wBpzwttfJbu/eG0vkJKvr1pMEjf3ZmdXEE1+bdHMNTHO8F1+AeOtrSAk2norSIUEAa0IaBzLBd399nwIvSUMtVkEZgiMRBxtvKFbHJ+szYDo5d+0yOKDQjKv2pns2BH/CG78ugfqsoCY04NE=",
"created_at": "2020-08-13 15:41:01.310 +0300",
"ca_extra": {
"privyId": "123456",
"privyId_enrollmentCode": "123456",
"privyId_merchantKey": "123456"
},
"transactionid": "06a2a194-d1ad-4de0-a877-4f5d77a6b31d",
"status": 3
},
"key_info": {
"eventid": 0,
"is_deleted": 0,
"key_content": "750230565d54755b3d2c160411216a5d6b796b59681441456a2e21727b1a0736606532406a16181d706408052076410b22001b53251f5c3c395d7657530e3c37",
"key_flags": 2048,
"keyid": 9,
"created_at": "2020-05-28 17:33:19.578 +0300",
"user_key_version": 1,
"expiration_date": "2021-05-28 17:33:19.577 +0300",
"userid": "rest-api-test-926c3ecf-a683-4510-be0d-d1d9d40ddead"
},
"cms_created_at": "2020-08-13 17:46:39.0 +0300"
}
],
"check_error_code": 0
}
},
"answer_version": 3
}
This endpoint should be used to check digital signature from signed PDF, generated by PC with user's certificate.
During execution CMS signature will be extracted from signed PDF and verified like in Check CMS Signature endpoint.
CMS signature MUST contain signed attribute with OID 1.2.840.113549.1.9.5 (signing-time) to identify PC user's details for exact moment.
If someone wants to check signed PDF then he can do this with this endpoint.
Request params:
| Parameter | Mandatory | Description |
|---|---|---|
| system_id | y | Identifier of PC System |
| user_id | y | PC user's identifier |
| transaction_data.binary_data | y | signed PDF to be verified |
Response contains result object and check_pdf_result object which equals to check_cms_result (see Check CMS Signature )
Get User Detailed Information
endpoint: {{pc-server-api}}/rks/user_data
method: POST
Request sample
{
"system_id":"{{system_id}}",
"user_id":"{{user_id}}",
"date_from": "2020-05-12 23:37:53.0 +0300",
"date_to": "2020-05-12 23:37:54.0 +0300",
"active_only":true
}
This endpoint should be used to get detailed information about user, including keys, events, devices and so on.
Request params:
| Parameter | Mandatory | Description |
|---|---|---|
| system_id | y | Identifier of PC System |
| user_id | y | PC user's identifier |
| date_from | y | Date in string format to get information form |
| date_to | y | Date in string format to get information to |
| active_only | y | exclude information marked as "deleted" |
Response will contain detailed information about user.
Get Transactions Detailed Information
endpoint: {{pc-server-api}}/rks/transaction_data
method: POST
Request sample
{
"system_id":"{{system_id}}",
"user_id":"{{user_id}}",
"date_from": "2018-10-09 00:00:00.0 +0300",
"date_to": "2021-12-09 12:00:00.0 +0300",
"active_only":true
}
This endpoint should be used to get detailed information about transactions for a user.
Request params:
| Parameter | Mandatory | Description |
|---|---|---|
| system_id | y | Identifier of PC System |
| user_id | y | PC user's identifier |
| date_from | y | Date in string format to get information form |
| date_to | y | Date in string format to get information to |
| active_only | y | exclude information marked as "deleted" |
Response will contain detailed information about user's transaction for specified period.
Get Events Detailed Information
endpoint: {{pc-server-api}}/rks/event_data
method: POST
Request sample
{
"system_id":"{{system_id}}",
"user_id":"{{user_id}}",
"date_from": "2018-10-09 00:00:00.0 +0300",
"date_to": "2021-12-09 12:00:00.0 +0300",
"active_only":true
}
This endpoint should be used to get detailed information about events for a user.
Request params:
| Parameter | Mandatory | Description |
|---|---|---|
| system_id | y | Identifier of PC System |
| user_id | y | PC user's identifier |
| date_from | y | Date in string format to get information form |
| date_to | y | Date in string format to get information to |
| active_only | y | exclude information marked as "deleted" |
Response will contain detailed information about user's events for specified period.
Errors
PC can return following errors:
| Code | Name | Meaning |
|---|---|---|
| 0 | NORMAL | Success |
| 100 | JAVA_INTERNAL_ERROR | Internal Error |
| 200 | SYSTEM_PROPERTY_ERROR | System property error |
| 201 | SYSTEM_ID_IS_NULL | System ID is null |
| 202 | SYSTEM_ID_IS_WRONG | System ID is wrong |
| 203 | SYSTEM_NOT_FOUND | System not found |
| 204 | SYSTEM_IS_DELETED | System has been deleted |
| 205 | SYSTEM_NAME_IS_NULL | System name is null |
| 206 | USER_ID_IS_NULL | User ID is null |
| 207 | USER_ID_PREF_IS_NULL | User ID prefix is null |
| 208 | USER_NOT_FOUND | User not found |
| 209 | USER_IS_DELETED | User has been deleted |
| 210 | DS_VERIFY_ERROR | Digital signature is not valid |
| 211 | DS_STRUCT_ERROR | Digital signature is corrupted |
| 212 | STORE_TYPE_IS_WRONG | Key storage type is unsupported |
| 213 | KEY_CONTAINER_ALIAS_IS_NULL | Key alias is null |
| 214 | KEY_CONTAINER_NOT_EXISTS | Key container does not exist |
| 215 | TRANSACTION_DATA_UID_ERROR | Transaction data is corrupted (User ID does not match) |
| 216 | TRANSACTION_DATA_ERROR | Transaction data error |
| 217 | TRANSACTION_DATA_IS_NULL | Transaction data is null |
| 218 | REPORT_TPL_IS_NULL | Report template is null |
| 219 | REQUEST_ERROR | Request error |
| 220 | SYSTEM_ID_NOT_UNIQUE | System ID is not unique |
| 221 | REQUEST_SIGNATURE_NOT_VALID | Requset digital signature invalid |
| 222 | SYSTEM_NOT_VALID | System is not valid |
| 231 | TRANSACTION_IS_NULL | Transaction is NULL |
| 232 | TRANSACTION_CHECKED | Transaction is confirmed |
| 233 | ERROR_PARSE_REGISTER_SYSTEM_INFO | Request is corrupted |
| 234 | INCORRECT_USER_TYPE | User type is incorrect |
| 235 | COLLECTION_IS_EMPTY | Collection is empty |
| 236 | NO_RESULT | Empty result |
| 237 | PIN_IS_EMPTY | PIN is empty |
| 238 | FPRINT_IS_EMPTY | Fingerprint is empty |
| 239 | OTP_IS_NOT_VALID | Offline confirmation code is not valid |
| 240 | VALID_DATE_EXPIRED | Key has expired |
| 241 | SYSTEM_TYPE_IS_WRONG | System type is not valid |
| 242 | SPART_LENGTH_IS_WRONG | Second key part length is not valid |
| 243 | DATA_TYPE_IS_WRONG | Data type is wrong |
| 244 | INVALID_HMAC | HMAC is not valid |
| 245 | KEY_INFO_NOT_FOUND | User key not found |
| 246 | WRONG_SYSTEM_TYPE | System type is not valid |
| 247 | FPRINT_IS_NOT_EMPTY | Fingerprint is already set |
| 248 | WRONG_AUTH_CODE | Authentication code is invalid |
| 249 | CONFIRM_TYPE_IS_NULL | Confirm type is null |
| 250 | STORE_TYPE_IS_NULL | Key store type is null |
| 251 | DEVICE_TYPE_IS_NULL | Device type is null |
| 252 | TRANSACTION_DATA_TYPE_IS_NULL | Transaction data type is null |
| 253 | USER_ID_PREF_TOO_LONG | User ID Prefix is too long |
| 254 | CONFIRM_CODE_LENGTH_IS_WRONG | Confirmation code length is not valid |
| 255 | CONFIRM_CODE_IS_NULL | Confrimation code is null |
| 256 | TRANSACTION_ID_IS_NULL | Transaction ID is null |
| 257 | STATUS_LIST_IS_EMPTY | Transaction status list is empty |
| 258 | DEVICE_ID_IS_NULL | Device ID is null |
| 259 | DEVICE_TYPE_IS_INCORRECT | Device type is incorrect |
| 261 | INVALID_OTP | Offline confirmation code is not valid |
| 263 | INVALID_KDF | Export param format is not valid |
| 264 | PIN_LENGTH_IS_WRONG | PIN length is invalid |
| 265 | PUSH_ID_IS_NULL | PUSH ID is null |
| 267 | TRANSACTION_STATUS_INVALID | Invalid transaction status |
| 268 | AUTH_CODE_IS_NULL | Authentication code is null |
| 269 | STATUS_LIST_IS_INCORRECT | Status list is incorrect |
| 270 | DECLINE_REASON_IS_NULL | Decline reason is null |
| 271 | TRANSACTION_IS_NOT_UNIQUE | Transaction is not unique |
| 272 | BILL_DATE_CORRUPTED | Billing date is corrupted |
| 273 | USER_BILL_DATE_CORRUPTED | User billing date is corrupted |
| 274 | TRANSACTION_IS_DELETED | Transaction is marked as deleted |
| 275 | BILL_REQUEST_ALREADY_PROCESSED | Request for close billing already processed |
| 276 | PUBKEY_IS_EMPTY | Public key is empty |
| 277 | PUBKEY_IS_NOT_EMPTY | Public key was already set |
| 278 | SIGNATURE_IS_INVALID | Signature is invalid |
| 279 | SIGNATURE_IS_NULL | Signature is null |
| 280 | SIGNATURE_AND_CONFIRM_CODE_ARE_NULL | Signature or confirm code must be specified |
| 281 | TRANSACTION_EXPIRED | Transaction expired |
| 282 | JSON_SCHEME_NOT_SUPPORTED | JSON scheme not supported |
| 283 | JSON_REQUEST_INCORRECT | JSON request is incorrect |
| 284 | LICENSE_UPDATE_ERROR | License update error |
| 285 | LICENSE_EXPIRED | License expired |
| 286 | LICENSE_USER_COUNT_EXCEEDED | Licensed users count exceeded |
| 287 | BILLING_TYPE_CORRUPTED | Billing type corrupted in database |
| 288 | HTTP_AUTH_CODE_INVALID | HTTP Authorization failed |
| 289 | NOT_SUPPORTED | Operation not supported |
| 290 | EXT_AUTH_TEMPLATE_NOT_FOUND | Extended authentication template not found |
| 291 | EXT_AUTH_FAILED | Extended authentication failed |
| 292 | EXT_AUTH_TYPE_NOT_SUPPORTED | Extended authentication type not supported |
| 293 | EXT_AUTH_NEEDED | Extended authentication needed |
| 294 | USER_IS_BLOCKED | User is blocked |
| 295 | KEY_EXPIRED | The key has been expired, to continue you should update the key |
| 296 | LICENSE_NOT_FOUND | License not found |
| 297 | PUSH_NOT_FOUND | Device ID not found |
| 298 | SCORING_SETTINGS_IS_NULL | Scoring settings not set |
| 299 | AUTOSING_SIGNATURE_IS_INVALID | Signature for autoconfirm is invalid |
| 300 | SERVER_SCORING_SETTINGS_INCORRECT | Scoring settings are invalid on the server |
| 301 | SCORING_FAILED | Scoring failed |
| 302 | HIGH_SCORING_RISK_LEVEL | Scoring risk level is very high |
| 304 | AUTOSIGN_FAILED | Transaction autoconfirm failed |
| 305 | AUTOSIGN_NOT_ALLOWED | Autoconfirm is not allowed |
| 306 | ATTEMPT_ID_IS_NULL | Attempt ID not set |
| 307 | FLEXIBLE_LICENSE_ERROR | Flexible license error |
| 308 | UNSUPPORTED_BILLING_TYPE | Unsupported billing type |
| 309 | LICENSE_ERROR | License error |
| 310 | OPERATION_NOT_EXISTS | Operation not exists |
| 311 | TRANSACTION_IS_NOT_IN_OPERATION | Transaction is not in operation |
| 312 | OPERATION_STATUS_INVALID | Operation status invalid |
| 313 | CREATE_OPERATION_ERROR | Create operation error |
| 314 | REMOTE_UPDATE_ERROR | Remote update error, attempts remained: |
| 315 | REMOTE_UPDATE_ERROR_BLOCK | Remote update error, user was blocked |
| 316 | REMOTE_UPDATE_DISABLED | Remote update disabled |
| 317 | OPERATION_EXPIRED | Operation has been expired |
| 318 | DN_IS_NULL | Distinguished Name not set |
| 319 | CERT_REQUEST_PARAMS_IS_NULL | Certificate request params not set |
| 320 | CERT_ISSUE_ERROR | Certificate issuing error |
| 321 | NO_CERT_REQUEST | Certificate Request or Certificate is absent |
| 322 | NO_CERT | No certificate for this operation |
| 323 | NO_PKI_SETTINGS_DEFINED | No PKI settings defined in service configuration |
| 324 | CAN_NOT_USE_CERTIFICATE_CHAIN | Can not use one or more certificates in provided chain |
| 325 | CERT_STATUS_INVALID | Certificate status invalid for this operation |
| 326 | CERT_REVOKE_ERROR | Certificate revocation error |
| 327 | CERT_DOES_NOT_MATCH | Certificate in CMS does not match with certificate for a user |
| 328 | INCORRECT_TRANSACTION_TYPE | Incorrect transaction type |
| 329 | INCORRECT_ACCESS_PERMISSIONS | Incorrect access permissions for signed PDF |
| 330 | INCORRECT_PDF_DATA | Incorrect PDF data |
| 331 | PDF_DATA_NOT_COMPLIES_CMS | PDF data not complies CMS-signature |
| 333 | URL_TEMPLATE_NOT_DEFINED | URL template for Deep Link is not defined |
| 334 | PUBKEY_SIGNATURE_IS_EMPTY | Signature to change public key is not defined |
| 335 | AUTOSIGN_PUBKEY_SIGNATURE_IS_EMPTY | Signature to change auto-sign public key is not defined |
| 336 | KEY_INDEX_OBSOLETED | The key has been replaced with new one |
| 337 | KEY_INDEX_WRONG | Server can not find your key with defined index |
| 338 | DEVICE_FINGERPRINT_MISMATCH | Device fingerprint mismatch |
| 339 | REQUEST_IS_LOCKED_BY_ANOTHER_REQUEST | The same request is in progress |
| 340 | KEY_NOT_ACTIVATED | The key is not activated |
| 341 | ACTIVATION_ATTEMPTS_EXCEEDED | Activation attempts count exceeded |
| 342 | ACTIVATION_CODE_INCORRECT | Incorrect activation code. Attempts left: |
| 343 | PASSWORD_ATTEMPTS_EXCEEDED | Enter password attempts exceeded |
| 344 | PASSWORD_INCORRECT | Incorrect password. Attempts left: |
| 345 | PASSWORD_NOT_SET | Password is not defined |
| 346 | CREDENTIALS_NOT_INITIALIZED | Password is not defined |
| 347 | GOST_IMIT_DOESNT_MATCH | GOST imit mismatch |
| 348 | EVENTS_REMOVEMENT_IS_NOT_ALLOWED | Events remove is not allowed |
| 349 | TIME_SYNC_ERROR | Time between mobile device and PC Server is not synchronized |
| 350 | QR_GENERATION_ERROR | Can not generate QR-code, data is too long |
| 351 | CRYPT_TYPE_IS_NOT_DEFINED | Crypt type is not defined |
| 352 | FEATURE_IS_NOT_LICENSED | The feature is not licensed |
Changelog
version: 6.4.0
Added
- Implemented persistent storage of GOST keys in the database. This enhancement ensures reliable storage of keys in scenarios where the application is run in a container environment or in a distributed architecture with multiple instances of PC Server Signer. This solution enhances system stability and security by ensuring key availability even during restarts or load distribution across instances.
Fixed
- Minor bugs fixes and other improvements.
version: 6.3.2
Fixed
- The update to version 9.3.0 of the Firebase Admin Java SDK (com.google.firebase). This fixes bug with sending pushes through sendAll() method.
version: 6.3.1
Example
docker run -d \
-v /path/to/cert.pem:/opt/certs/cert.pem \
-e TRUST_CERT=/opt/certs/cert.pem \
your-pc-module-image
Added
- New Feature: Automatic Truststore update for PC modules in Docker Containers.
A new feature has been added to Docker images to enhance the handling of self-signed certificates. This feature allows you to easily add custom certificates to the Java truststore within a Docker container.
How it Works:
- Mount Certificate: Mount a certificate in PEM or DER format to the Docker container.
- Environment Variable: Set the environment variable
TRUST_CERTto the path of the mounted certificate. - Truststore Update: The container will automatically add the certificate specified by the TRUST_CERT variable to the Java truststore.
version: 6.3.0
Added
- Enhanced ServerSigner to support verifying signature of arbitrary data.
- Added timezone in visualizing signature stamp in PDF (mobile device timezone if events are switched on or server timezone)
Fixed
- Fixed database indexes
version: 6.2.0
Added
- Enhanced ServerSigner to support signing of arbitrary data.
Fixed
- Fixed reusing of delayed key-info with online-credentials flag.
- Prevented logs from being spammed with NO_PKI_SETTINGS_DEFINED error.
- Fixed logging level in pusher for missing default credentials message.
- Addressed issue with PC Server Signer hanging during entropy formation for ГОСТ key pairs.
- Minor fixes and improvements.
version: 6.1.2
- pc-server jar and it's libs packed to single file for web repo publishing
version: 6.1.1
Fixed
- Fixed incorrect generation of links for PCS requests in ServerSigner. Now all interaction between PC Server and PC Server Signer is carried out via PC External in case of PC Server Signer is externally hosted.
- Minor fixes and improvements.
version: 6.1.0
Added
- Support for GOST cryptography in PC Server Signer.
- Ability to deploy PC Server Signer in a network segment other than PC Server.
- Licensing mechanism for JCP in PC Server Signer.
Changed
- Added additional metadata to the response of /healthcheck endpoint: (Build timestamp, Build branch)
Fixed
- Various bug fixes and minor improvements.