错误处理 + 错误代码

运营商将收到以下格式和数据的错误响应：

错误响应 + 示例

{ '错误'：1， 'error_id': 101, 'error_code': 'INVALID_TOKEN', 'error_message'：“无效令牌”" }

< td>1表示失败，0表示成功，

响应对象中的对象/键	类型	描述
error	Integer
error_id	Integer	错误ID
error_code	code>整数	错误码
error_message< /td>	String	可选。 人类可读的错误信息

所有 POST 参数的常见错误代码和消息列表

以下是 POST 参数的常见错误代码。 这些将验证是否缺少任何必需的 POST 参数，它是否为空，参数的长度和大小等。 同一错误代码可用于多个 POST 参数。

ID	Code	Message
2001	INVALID_%field_name%	%field_name% is required.
2002	INVALID_%field_name%	%field_name% should not be null.
2003	INVALID_%field_name%	%field_name% should not be blank.
2004	INVALID_%field_name%	%field_name% should be at least %error_value% characters long.
2005	INVALID_%field_name%	%field_name% should not be more than %error_value% characters
2006	INVALID_%field_name%	String is invalid.
2007	INVALID_%field_name%	Email is invalid.
2008	INVALID_%field_name%	A valid integer is required.
2009	INVALID_%field_name%	The value should be equal or less than %error_value%.
2010	INVALID_%field_name%	The value should be equal or more than %error_value%.
2011	INVALID_%field_name%	Too large string value.

In the above table “%field_name%” can be any expected parameter that must be sent in the POST data. For example, let us take below POST data. 

{"api_key":"1pghjl4v5apt2bks", "username":"test_user","password":"test1234","transaction_id":1234}

在这种情况下，API 调用者不会在 POST 数据中发送 ‘transaction_id’，RGS API 将以游戏提供商（游戏引擎 + RGS）内部的以下格式向调用者发送错误消息:

{ "error": 1, "error_detail": { "id": 2001, "code": "INVALID_TRANSACTION_ID", "message": "需要交易ID。" } }

< td>1表示有错误，0表示无错误，

响应对象中的对象/Key	类型	描述
error	整数
error_detail	JSON 对象	有3个key id
id	整数	错误 ID
code	字符串	错误代码
message	字符串	可选。 人类可读的错误信息

错误 ‘code’ 将是 “INVALID_” 后跟缺少的大写参数名称，即 “INVALID_TRANSACTION_ID” 和‘message’ 将是‘不带下划线的参数名称，由空格分隔的单词’，后跟‘是必填的.’ 例如‘交易 ID是必填的’。

当 POST 数据中缺少“transaction_id”参数时

ID	Code	Message
2001	INVALID_%field_name% will be interpreted as INVALID_TRANSACTION_ID	“%field_name% is required.” will be interpreted as “Transaction id is required.”
2002	INVALID_%field_name% will be interpreted as INVALID_TRANSACTION_ID	“%field_name% should not be null.” will be interpreted as “Transaction id should not be null.”
2003	INVALID_%field_name% will be interpreted as INVALID_TRANSACTION_ID	“%field_name% should not be blank.” will be interpreted as “Transaction id should not be blank.”

从 id 2001 到 2011 所有符合上述验证标准的 POST 参数也是如此。

错误代码和消息列表（不包括常见代码和消息）

20182022 /tr>< td>运营商和 opus 之间的玩家货币不匹配FALIED_TRANS

ID	Code	Message
2012	INVALID_LOGIN_CREDENTIALS	无法使用提供的凭据登录。
2013	INVALID_LOGIN_CREDENTIALS	必须包含用户名和密码。
2014	INVALID_LOGIN_CREDENTIALS	用户不属于该网站。
2015/td>	INVALID_API_KEY	API 密钥无效
2016	INVALID_SESSION_ID	无效会话ID
2017	INVALID_PROVIDER	提供商无效
INVALID_GAME_TYPE	游戏类型无效
2019	INVALID_PLATFORM	平台无效
2020< /code>	INVALID_AMOUNT_TYPE	金额类型无效
code>2021	INVALID_PLAYER_ID	玩家ID无效
INVALID_GAME_ID	游戏 ID 无效。
2023	INVALID_LANGUAGE	无效语言。
2024	INVALID_USERNAME	无效的用户名。
2025	CURRENT_NEW_PASSWORD_SAME	新密码不得与当前密码相同。
2026	INVALID_CURRENCY	无效货币。
2027	NEGATIVE_AMOUNT_VALUE	Amount 应该是正值。
2028	INSUFFICINT_BALANCE	余额不足。
2029	INVALID_STARTDATE_ENDDATE	开始日期不应晚于结束日期。
2030	INVALID_AMOUNT_VALUE	金额应小于余额。
2031	DUPLICATE_SESSION_ID	会话 ID 重复。
2032	OPERATOR_AUTHENTICATION_FAIL	运营商认证失败。
2033	CURRENCY_MISMATCH
2034	ZERO_AMOUNT_VALUE< /code>	金额应大于零。
2035	交易未找到或失败。
2036< /code>	INVALID_FROM_DATE	起始日期晚于截止日期。
2037	INVALID_TIME_INTERVAL	时间间隔超出允许范围。
2038	INVALID_MONETARY_TYPE	货币类型无效。