Receive beneficiary binding result notification
After successfully binding a new beneficiary to a Zyla account, Zyla uses this API to notify you of the beneficiary binding result.
Structure
A message consists of a header and body.
Request header
Field | Required | Sample | Description |
| Client-Id | Yes | Client-Id: ***** | For more information about these request header fields, see Request header. |
| Signature | Yes | Signature: algorithm=RSA256, keyVersion=2, signature=***** | |
Content-Type | Yes | Content-Type: application/json; charset=UTF-8 | |
| Request-Time | Yes | Request-Time: 2019-04-04T12:08:56+08:00 |
Request parameters
bindBeneficiaryRequestId String REQUIRED
The unique ID assigned by the Partner to identify a request for beneficiary binding.
More information:
- This field is an API idempotency field.For details about API idempotency, see the Idempotency chapter.
- Maximum length: 64 characters
result Result REQUIRED
Indicates the result of beneficiary binding.
beneficiary Beneficiary REQUIRED
Describes details about the beneficiary.
This field is returned as needed only when result.resultStatus =S.
Response parameters
result Result REQUIRED
Indicates whether this API is called successfully.
Request
Response
Result processing logic
Zyla sends you the binding result with the bindingResult.result parameter in the request. For details, see the following bindingResult.resultCode section. After receiving the result notification, you need to send a response to acknowledge receipt of the notification.
Note: You must sign the message before sending the response. For details, see Sign a request and validate the signature and Response header.
If you do not send the acknowledgment back to Zyla, Zyla retries to send the result by complying with the following rules:
- Zyla retries notifications 7 times at most.
- Intervals between notifications: 2m, 10m, 10m, 1h, 2h, 6h, and 15h.
result.resultCode
| Code | Value | Message | Further action |
|---|---|---|---|
| SUCCESS | S | Success | |
| PROCESS_FAIL | F | A general business failure occurred. Do not retry. | Human intervention is usually needed. Contact our Technical Support Team to resolve the issue. |
| UNKNOWN_EXCEPTION | U | API failed due to unknown reason. | The service might be down, retry later. If the issue persists, contact our Technical Support Team. |
bindingResult.resultCode
| Code | Value | Message | Further action |
|---|---|---|---|
| UN_SUPPORT_BUSINESS | F | Unsupported business. | Invalid parameters are used e.g. currency is incorrect. Retry with the correct information. |
| USER_NOT_EXIST | F | The user does not exist. | Retry with the correct user information. |
| RISK_REJECT | F | The transfer is rejected for risk control reasons. | Prompt the user that the request is rejected because the risk control failed. |
| REPEAT_BIND_BENEFICIARY_REQUEST | U | Repeated request to bind a beneficiary. | Check whether the beneficiary has already been successfully bound with the inquiryBeneficiary API. |
| USER_NO_PERMISSION | F | User does not have permission. | Check the permission of the user and retry. |
| BENEFICIARY_ALREADY_EXISTED | U | Beneficiary already existed. | Check whether the beneficiary has already been successfully bonded with the inquiryBeneficiary API. |
| REPEAT_REQ_INCONSISTENT | F | Repeated requests are inconsistent. | Ensure all the fields in the requests are the same. |
| REFERENCE_BENEFICIARY_ID_EXIST | F | Reference beneficiary id exist. | Check whether the beneficiary has already been successfully bound. |
| CARD_TEMPLATE_NOT_EXIST | F | No card templates met the query conditions. | Check whether the correct beneficiary template has been used. |