රීසෙලර්ලා සඳහා වන REST API - v1 අනුවාදය
රීසෙලර්වරුන් සඳහා ගේම් ටොප් අප් සහ වවුචර API
ගේම් ටොප් අප්, ගේම් රීචාජ් සහ වවුචරයේ කෝඩ් සඳහා එකම REST API එකක්. මෙයින් නාමාවලිය කියවා ක්රීඩකයා තහවුරු කර ඇණවුමක් සාදන්න. ප්රතිඵලය webhook මගින් හෝ තත්ත්වය විමසන status poll එකකින් ලබාගන්න.
මෙය SHOP2TOPUP පිටුපස ක්රියා කරන host-to-host (H2H) ටොප් අප් API එකයි. HTTPS ඔස්සේ ක්රියා කරන සරල JSON API එකක් වන මෙහි Bearer සත්යාපනය, UUID idempotency key, ප්රසිද්ධ කළ ඉල්ලීම් සීමා සහ යන්ත්රවලට කියවිය හැකි ස්ථාවර දෝෂ කේත ඇත. ඒ නිසා වෙළඳසැලකට, වෙබ් ස්ටෝර් එකකට හෝ bot එකකට කිසිදු client library එකක් නැතිව ඩිජිටල් ගේම් ක්රෙඩිට් ක්රමලේඛනය හරහා විකිණිය හැක. අඛණ්ඩව වසර 5+ ක් ක්රියාත්මක වෙමින්, මෙම අතුරුමුහුණත හරහාම ඇණවුම් 3,000,000+ ක් ලබා දී ඇත.
මිල ගණන්, ගෙවීම් ක්රම සහ partner ගිණුම ක්රියා කරන ආකාරය ගැන දැනගැනීමට මෙය කියවන්න: SHOP2TOPUP රීසෙලර් වැඩසටහන පිළිබඳ දළ විශ්ලේෂණය.
කිසිවකට අත්සන් කිරීමට පෙර ඔබේ පළමු API call එක
සෑම endpoint එකක්ම එක් ශීර්ෂයක් (header) සහිත සාමාන්ය HTTPS ඉල්ලීමකි. ස්ථාපනය කිරීමට SDK එකක්, ව්යාපෘතියට එක් කළ යුතු client library එකක් හෝ අමතර build පියවරක් අවශ්ය නැත. පහත ඇති ඉල්ලීම අලවා, ඔබේ key එක ඇතුළත් කරන්න. එවිට සජීවී කැටලොග් ප්රතිචාරයක් ඔබේ ටර්මිනලයේම දැකිය හැක.
curl -s "https://shop2topup.com/api/endpoints/v1/catalog/categories?bigCategoryId=1" \
-H "Authorization: Bearer YOUR_KEY_ID.YOUR_KEY_SECRET"{
"success": true,
"categories": [
{
"id": 12,
"name": "Free Fire",
"description": "Garena Free Fire diamonds",
"big_category_id": 1,
"big_category_name": "Mobile Games"
}
]
}මූලික URL ලිපිනය
https://shop2topup.com/api/endpoints/v1
ලේඛනගත සෑම මාර්ගයක්ම මෙම base එකට සාපේක්ෂ වේ. ප්රතිචාර JSON ආකාරයෙන් ලැබෙන අතර සැමවිටම boolean success field එකක් අඩංගුය. ඒ නිසා ඔබේ client එකේ එක branch එකකින් සාර්ථක අවස්ථාව අනෙක් සියල්ලෙන් වෙන් කළ හැක.
දෝෂ ප්රතිචාරයේ ආකෘතිය
සෑම status code එකකදීම දෝෂ ප්රතිචාර ලැබෙන්නේ එකම ආකෘතියෙනි. contract එකේ කොටසක් වන error.code අනුව වැඩසටහනේ ක්රියාමාර්ග තීරණය කරන්න. error.message අනුව කිසිවිටෙක එවැනි තීරණ ගන්න එපා. එය මිනිසුන්ට කියවීමට ලියන පණිවිඩයක් නිසා එහි වචන ඕනෑම වේලාවක වෙනස් විය හැක.
{
"success": false,
"error": {
"code": "PRICE_INCREASED",
"message": "Price has increased beyond expected",
"action": "FIX_INPUT",
"retryable": false,
"retry_after": null,
"details": {
"expected_unit_price": "0.950000",
"current_unit_price": "0.980000"
}
}
}මුළු API එකම එක තිරයකින්
endpoints 11කින් සම්පූර්ණ integration එකම ආවරණය වේ: catalog එක කියවීම, අයිතමයක මිල බැලීම, player පරීක්ෂා කිරීම, ඇණවුමක් දැමීම සහ පසුව එය reconcile කිරීම. සෑම පේළියක්ම සම්පූර්ණ ලේඛනයට කෙලින්ම යොමු කරයි. එහි සෑම parameter එකක්ම, උදාහරණ ඉල්ලීමක් සහ උදාහරණ ප්රතිචාරයක් ඇත.
| ක්රමය | මාර්ගය | කාර්යය | ලේඛනය |
|---|---|---|---|
| GET | /account | ගිණුම් තොරතුරු ලබා ගන්න | ලේඛනය කියවන්න |
| GET | /catalog/big-categories | ප්රධාන කාණ්ඩ ලැයිස්තුව | ලේඛනය කියවන්න |
| GET | /catalog/categories | කාණ්ඩ ලැයිස්තුව | ලේඛනය කියවන්න |
| GET | /catalog/subcategories | උප කාණ්ඩ ලැයිස්තුව (නිෂ්පාදන) | ලේඛනය කියවන්න |
| GET | /catalog/subcategory/:itemId/price | අයිතමයේ මිල ලබා ගන්න | ලේඛනය කියවන්න |
| GET | /catalog/category/:categoryId/requirements | කාණ්ඩයේ අවශ්යතා ලබා ගන්න | ලේඛනය කියවන්න |
| POST | /player/validate | ක්රීඩකයා තහවුරු කරන්න | ලේඛනය කියවන්න |
| POST | /orders/create | ඇණවුමක් සාදන්න | ලේඛනය කියවන්න |
| GET | /orders/:orderId | ඇණවුමේ තත්ත්වය ලබා ගන්න | ලේඛනය කියවන්න |
| POST | /orders/batch | ඇණවුම් එකවර ලබා ගන්න | ලේඛනය කියවන්න |
| GET | /orders | ඇණවුම් ලැයිස්තුව | ලේඛනය කියවන්න |
ඊට අමතරව ඇණවුම් status webhooks ද ඇත. ඒවා මෙම පිටුවේ පහළින් සම්පූර්ණයෙන් විස්තර කර ඇත.
සත්යාපනය සහ ප්රවේශ පාලනය
සත්යාපනයට අවශ්ය වන්නේ එක් HTTP ශීර්ෂයක් පමණි. සෑම ඉල්ලීමකම Authorization ශීර්ෂයේ Bearer අක්තපත්රයක් ඇත. එය key ID එකකින් සහ රහස් අගයකින් (secret) සමන්විත වන අතර, ඔබේ රීසෙලර් පැනලයේ API Access පිටුවෙන් නිකුත් කෙරේ. key ID එකෙන් ගිණුම හඳුනා ගනී. රහස් අගයෙන් ගිණුම ඔබට අයත් බව ඔප්පු වන අතර, එය සර්වර් පැත්තේ HMAC පරීක්ෂාවකින් තහවුරු කෙරේ.
secret එක පෙන්වන්නේ එය සාදන අවස්ථාවේදී එක් වරක් පමණි. ඉන්පසු එය නැවත ලබාගත නොහැක. භාවිත කරන තාක්ෂණ පද්ධතියේ දැනටමත් ඇති secret manager එකේ එය ගබඩා කර, environment variable එකක් හරහා යෙදුමට ලබා දෙන්න. එය source control එකට ඇතුළත් නොකරන්න. එය නැති වුවහොත් නැවත ලබාගැනීම වෙනුවට අලුත් secret එකකට මාරු විය යුතුය.
මෙහි OAuth redirect එකක්, session cookie එකක් හෝ refresh token එකක් නැත. කාලසටහනකට අනුව කළ යුතු කිසිම දෙයක්ද නැත. ස්වයංක්රීය ඒකාබද්ධ කිරීම්වලට මෙය වැදගත් වේ: cron job එකකට හෝ queue worker එකකට, අලුත් කිරීමේ ක්රියාවලියක් නැතිව එකම අක්තපත්රය වසර ගණනාවක් තබා ගත හැක. අලුයම තුනට ඔබව අවදි කරන කල් ඉකුත් වීමක්ද නැත.
key එකකට IP අවසර ලැයිස්තුවක් (allowlist) සම්බන්ධ කළ හැක. ලැයිස්තුව හිස් නැති විට, වෙනත් ඕනෑම ලිපිනයකින් එන ඉල්ලීම් කිසිදු ව්යාපාරික තර්කනයක් ක්රියාත්මක වීමට පෙර IP_NOT_ALLOWED සහ HTTP 403 සමඟ ප්රතික්ෂේප වේ. ඒ නිසා අක්තපත්රයක් කාන්දු වුවත්, ඔබේම සර්වර්වලින් පිටත එයින් කිසිම ප්රයෝජනයක් නැත. key මාරු කිරීම migration එකක් නොව සාමාන්ය deploy එකකි: අලුත් key එක සාදන්න, එය deploy කරන්න, පසුව පැරණි key එක මකා දමන්න.
සෑම key එකක්ම එක් රීසෙලර් ගිණුමකට අයත් වන අතර, මුදල් වැය වන්නේ එම ගිණුමේ වොලට් එකෙනි. ඒ නිසා රහස් අගය (secret) කිසි විටෙක බ්රව්සරයකට, මොබයිල් ඇප් bundle එකකට හෝ පොදු repository එකකට ඇතුළත් කරන්න එපා. API එක ඔබේ backend එකෙන් අමතන්න. ඔබේ front end එක සම්බන්ධ විය යුත්තේ ඔබේම backend එකට පමණි. මෙහි ලේඛනගත කර ඇති සියල්ල ලියා ඇත්තේ සර්වර් එකකින් සර්වර් එකකට ඇමතුම් කරන අය සඳහායි.
Authorization: Bearer <keyId>.<secret>එක call එකකින් key එක තහවුරු කරන්න
GET /account යනු credential එකක health check එකයි. එය එකවර ප්රශ්න 3කට පිළිතුරු දෙයි: key එක සත්යාපනය වේද, ගිණුම සක්රීයද, ඔබ ඇණවුම් කිරීමට යන දේට ප්රමාණවත් ශේෂයක් වොලට් එකේ තිබේද යන්න. boot වන විට සහ ඕනෑම batch run එකකට පෙර එය ධාවනය කරන්න.
සත්යාපනය සහ ගිණුම පිළිබඳ ලේඛනය කියවන්නමුල සිට අගටම සම්පූර්ණ ඒකාබද්ධ කිරීමක්
API සම්බන්ධතාව සකස් කිරීමට පියවර හතරක් ඇත. පහත cURL, Node සහ PHP උදාහරණවලින් ඒ සියලු පියවර සජීවී API එක හරහා ක්රියාත්මක කළ හැක. අදාළ තැනට තමන්ගේ ප්රවේශ තොරතුරු යෙදූ පසු, උදාහරණ ලියා ඇති ආකාරයටම ක්රියාත්මක කළ හැක.
- 1
කැටලොගය කියවන්න
ප්රධාන කාණ්ඩවල සිට කාණ්ඩ හරහා උප කාණ්ඩ දක්වා පියවරෙන් පියවර යන්න. ඉන්පසු ඔබ විකිණීමට යන අයිතමයේ වත්මන් මිල කියවන්න. කාණ්ඩ ගස cache කර තබා ගන්න, නමුත් අයිතමයේ මිල සෑම විටම අලුතින් ලබා ගන්න.
- 2
ක්රීඩකයා පරීක්ෂා කරන්න
කිසිම මුදලක් අඩු වීමට පෙර, identifier එකෙන් in-game නම සහ කලාපය සොයාගන්න. ටයිප් කිරීමේ වැරදි සහ කලාප අතර සිදුවන වැරදි අල්ලාගන්නේ මෙතැනදීය.
- 3
ඇණවුම සාදන්න
UUID එකක් සාදා, එය ගබඩා කර, පසුව order_id ලෙස යවන්න. එය ඔබේ idempotency key එකයි. create ඉල්ලීමක් නැවත උත්සාහ කිරීමට ඇති එකම ආරක්ෂිත ක්රමය ද එයයි.
- 4
ලබාදීම තහවුරු කරන්න
ඇණවුම් status webhook එක එනතුරු රැඳී සිටින්න. ඔබේම timeout කාලය ඉක්මවූ පසුත් pending ලෙසම ඇති ඕනෑම ඇණවුමක් සඳහා status එක කියවන්න.
cURL - සම්පූර්ණ ක්රියාවලියකේතය පෙන්වන්නකේතය සඟවන්න
export S2T_KEY="YOUR_KEY_ID.YOUR_KEY_SECRET"
export S2T_BASE="https://shop2topup.com/api/endpoints/v1"
# 1. Find the item you want to sell.
curl -s "$S2T_BASE/catalog/subcategories?categoryId=12" \
-H "Authorization: Bearer $S2T_KEY"
# 2. Read the exact price you will be charged for it.
curl -s "$S2T_BASE/catalog/subcategory/999/price" \
-H "Authorization: Bearer $S2T_KEY"
# 3. Confirm the player exists BEFORE any money moves.
curl -s -X POST "$S2T_BASE/player/validate" \
-H "Authorization: Bearer $S2T_KEY" \
-H "Content-Type: application/json" \
-d '{"sub_category_id": 999, "player_id": "123456789", "server": "Asia"}'
# 4. Create the order. order_id is YOUR uuid and YOUR idempotency key.
curl -s -X POST "$S2T_BASE/orders/create" \
-H "Authorization: Bearer $S2T_KEY" \
-H "Content-Type: application/json" \
-d '{
"order_id": "01912345-6789-7abc-8def-0123456789ab",
"sub_category_id": 999,
"quantity": 1,
"requirements": { "player_id": "123456789", "server": "Asia" },
"expected_unit_price": "0.950000"
}'
# 5. Read the order back until it leaves "pending".
curl -s "$S2T_BASE/orders/01912345-6789-7abc-8def-0123456789ab" \
-H "Authorization: Bearer $S2T_KEY"සම්පූර්ණ ක්රියාවලිය - Node.jsකේතය පෙන්වන්නකේතය සඟවන්න
// Node 18+ — no dependencies, global fetch and global crypto.
const BASE = 'https://shop2topup.com/api/endpoints/v1';
const KEY = process.env.S2T_KEY; // "<keyId>.<secret>", server-side only.
async function call(path, init = {}) {
const res = await fetch(BASE + path, {
...init,
headers: {
Authorization: `Bearer ${KEY}`,
'Content-Type': 'application/json',
...(init.headers || {}),
},
});
if (res.status === 429) {
const wait = Number(res.headers.get('Retry-After') || 5);
await new Promise((r) => setTimeout(r, wait * 1000));
return call(path, init);
}
const body = await res.json();
if (!res.ok || body.success === false) {
throw Object.assign(new Error(body?.error?.code || 'HTTP_' + res.status), {
code: body?.error?.code,
status: res.status,
});
}
return body;
}
async function sell({ itemId, categoryId, playerId, server }) {
// 1 + 2. Catalog and current price.
const { subcategories } = await call(
`/catalog/subcategories?categoryId=${categoryId}`,
);
const item = subcategories.find((s) => s.item_id === itemId);
const { price } = await call(`/catalog/subcategory/${itemId}/price`);
// 3. Player check before charging.
const { player } = await call('/player/validate', {
method: 'POST',
body: JSON.stringify({
sub_category_id: itemId,
player_id: playerId,
server,
}),
});
// 4. Create the order. Persist orderId BEFORE the call so a crash mid-flight
// can be replayed with the same uuid instead of double-charging.
const orderId = crypto.randomUUID();
await saveIntent(orderId, itemId, playerId);
const { order } = await call('/orders/create', {
method: 'POST',
body: JSON.stringify({
order_id: orderId,
sub_category_id: itemId,
quantity: 1,
requirements: { player_id: playerId, server },
expected_unit_price: price.unit_price,
}),
});
// 5. Confirm. A webhook usually beats the poll; the poll is the safety net.
let status = order.status;
while (status === 'pending') {
await new Promise((r) => setTimeout(r, 20000));
status = (await call(`/orders/${orderId}`)).order.status;
}
return { orderId, status, itemName: item?.name, playerName: player.player_name };
}PHP - සම්පූර්ණ ක්රියාවලියකේතය පෙන්වන්නකේතය සඟවන්න
<?php
// PHP 8 — plain cURL, no SDK required.
const S2T_BASE = 'https://shop2topup.com/api/endpoints/v1';
function s2t(string $path, ?array $body = null): array
{
$ch = curl_init(S2T_BASE . $path);
$headers = [
'Authorization: Bearer ' . getenv('S2T_KEY'),
'Content-Type: application/json',
];
curl_setopt_array($ch, [
CURLOPT_RETURNTRANSFER => true,
CURLOPT_HTTPHEADER => $headers,
CURLOPT_TIMEOUT => 30,
]);
if ($body !== null) {
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($body));
}
$raw = curl_exec($ch);
$status = curl_getinfo($ch, CURLINFO_HTTP_CODE);
curl_close($ch);
$data = json_decode($raw, true) ?: [];
if ($status >= 400 || ($data['success'] ?? false) === false) {
throw new RuntimeException($data['error']['code'] ?? 'HTTP_' . $status);
}
return $data;
}
// 1 + 2. Catalog, then the exact price for the item.
$catalog = s2t('/catalog/subcategories?categoryId=12');
$price = s2t('/catalog/subcategory/999/price');
// 3. Player check before charging.
$player = s2t('/player/validate', [
'sub_category_id' => 999,
'player_id' => '123456789',
'server' => 'Asia',
]);
// 4. Create the order with your own uuid as the idempotency key.
$orderId = sprintf(
'%04x%04x-%04x-7%03x-%04x-%04x%04x%04x',
random_int(0, 0xffff), random_int(0, 0xffff),
random_int(0, 0xffff), random_int(0, 0x0fff),
random_int(0x8000, 0xbfff),
random_int(0, 0xffff), random_int(0, 0xffff), random_int(0, 0xffff)
);
$order = s2t('/orders/create', [
'order_id' => $orderId,
'sub_category_id' => 999,
'quantity' => 1,
'requirements' => ['player_id' => '123456789', 'server' => 'Asia'],
'expected_unit_price' => $price['price']['unit_price'],
]);
// 5. Read it back until it settles.
do {
sleep(20);
$latest = s2t('/orders/' . $orderId);
} while ($latest['order']['status'] === 'pending');
echo $latest['order']['status'];create call එකෙන් පසුව නොව, ඊට පෙර ඇණවුමේ UUID එක සුරකින්න. cache කළ අගය මත රඳා නොසිට මිල නැවත කියවන්න. මේ පියවර දෙක අනුගමනය කිරීමෙන් දෙවරක් මුදල් අය වීමේ සිදුවීම් සියල්ලම පාහේ සහ PRICE_INCREASED නිසා සිදුවන සියලු ප්රතික්ෂේප වීම් වළක්වා ගත හැක.
Webhooks: ඇණවුමේ තත්ත්වය ගැන එන කෝල්බැක්
එක් HTTPS endpoint එකක් ලියාපදිංචි කළ විට, ඇණවුම්වල ප්රතිඵල සිදුවූ විගස platform එක ඒවා එයට යවයි. එවිට ඔබේ storefront එක polling නවතා, ලැබෙන දේට අනුව ක්රියා කරයි. Callback එක අත්සන් කර ඇති බැවින්, ක්රියාත්මක වීමට පෙර payload එක අපෙන්ම ආ බව තහවුරු කරගත හැක.
සිදුවීම්
| සිදුවීම | යවන අවස්ථාව |
|---|---|
| order.completed | ඇණවුමේ එක් ඒකකයක් ලබා දී ඇත. සම්පූර්ණ ඇණවුමේ තත්ත්වය data.status හි බලන්න. |
| order.refunded | ඇණවුමේ එක් ඒකකයක මුදල් ඔබේ වොලට් එකට ආපසු ගෙවා ඇත. සියලු ඒකක ආපසු ගෙවූ පසු data.status හි refunded ලෙස පෙන්වයි. |
| webhook.test | හැන්ඩ්ලර් එක පරීක්ෂා කිරීම සඳහා පැනලයෙන් අත්සන් කළ ටෙස්ට් ලබාදීමක් ඔබ ආරම්භ කර ඇත. |
ලබාදීමේදී එවන හෙඩර්
| හෙඩරය | අගය |
|---|---|
| Content-Type | application/json |
| X-Shop2Topup-Signature | sha256=<hex> ආකාරයෙන්: ඉල්ලීමේ මුල් බොඩි එක කිසිදු වෙනසක් නොකර ගණනය කළ HMAC-SHA256 අගය |
| X-Shop2Topup-Event | සිදු වූ ඉවෙන්ට් එකේ නම, උදාහරණයක් ලෙස order.completed (ඇණවුම සම්පූර්ණයි) |
| User-Agent | shop2topup-webhook/1.0 |
කෝල්බැක් එකේ දත්ත
සෑම කෝල්බැක් එකකම ඉහළ මට්ටමේ ක්ෂේත්ර තුන එකමයි: event, timestamp සහ data. data තුළ ඇත්තේ තත්ත්වය බලන endpoint එකෙන් ලැබෙන ඇණවුම් වස්තුවමයි. වවුචර කෝඩ් ඇතුළත් වන්නේ ඇණවුම සම්පූර්ණයි නම් පමණි. player_name අගය null විය හැකිය. ඇණවුම ඒකකවලට බෙදුණු සෑම විටම sub_transaction_summary (උප ගනුදෙනුවල සාරාංශය) ක්ෂේත්රයද එකතු වේ.
{
"event": "order.completed",
"timestamp": "2026-03-11T14:30:00.000Z",
"data": {
"order_id": "01912345-6789-7abc-8def-0123456789ab",
"status": "completed",
"player_id": "123456789",
"player_name": "ProGamer99",
"subcategory_name": "FF 100 Diamonds",
"quantity": 1,
"charged_amount": "0.950000",
"currency": "USD",
"created_at": "2026-03-11T14:28:00.000Z",
"completed_at": "2026-03-11T14:30:00.000Z",
"vouchers": [
{
"code": "XXXX-YYYY-ZZZZ",
"serial_number": "SN-9928371",
"expiry_date": "2027-03-11"
}
],
"sub_transaction_summary": {
"total": 1,
"completed": 1,
"failed": 0,
"pending": 0,
"processing": 0,
"retrying": 0,
"refunded": 0
}
}
}අත්සන තහවුරු කිරීම
X-Shop2Topup-Signature හෙඩරය සෑම ලබාදීමකම ඇත. එහි අගය වන්නේ sha256= සහ ඊට පසුව එන hex HMAC-SHA256 අගයයි. එය ගණනය කරන්නේ ඔබේ webhook රහස් යතුර යොදා, මුල් ඉල්ලීම් බොඩි එක මතයි. තහවුරු කිරීම JSON parse කිරීමට පෙර, ලැබුණු මුල් බයිට් මතම කරන්න. සැසඳීම නියත කාලයක් ගන්නා ක්රමයකට කරන්න. බොඩි එක මුලින් parse කර පසුව තහවුරු කරන හැන්ඩ්ලර් එකක් නැවත serialise කළ බොඩි එකකින් රැවටිය හැකිය.
// Express — verify the signature against the RAW body, not the parsed object.
const crypto = require('crypto');
app.post(
'/shop2topup/webhook',
express.raw({ type: 'application/json' }),
(req, res) => {
const signature = req.get('X-Shop2Topup-Signature') || '';
const expected =
'sha256=' +
crypto
.createHmac('sha256', process.env.S2T_WEBHOOK_SECRET)
.update(req.body)
.digest('hex');
const a = Buffer.from(expected);
const b = Buffer.from(signature);
if (a.length !== b.length || !crypto.timingSafeEqual(a, b)) {
return res.status(401).end();
}
const payload = JSON.parse(req.body.toString('utf8'));
// Answer fast, then do the work. The delivery times out after 10 seconds.
res.status(200).end();
enqueueSettlement(payload.data.order_id, payload.event);
},
);යැවීම සහ නැවත උත්සාහ කිරීම
Callback එකක් යවන්නේ එක් වරක් පමණි. ඔබේ endpoint එකට පිළිතුරු දීමට තත්පර දහයක් ඇත. ස්වයංක්රීය retry හෝ exponential backoff එකක් නැති අතර එය හිතාමතාම ගත් තීරණයකි: නිල වාර්තාව status endpoint එකයි. එබැවින් reconciliation කළ යුත්තේ ඔබට නොපෙනෙන retry කාලසටහනකින් නොව, ඔබම පාලනය කරන poll එකකිනි. වහාම 200 ආපසු යවා, ඉතිරි වැඩ ඔබේම queue එකේ කරන්න.
නැවත ලැබුණත් එකම ප්රතිඵලය දෙන (idempotent) හැන්ඩ්ලර්
callback හසුරුවන විට order_id අනුව ඇණවුම හඳුනාගන්න. එකම callback එක නැවත ලැබුණොත් කිසිදු වෙනසක් සිදු නොවන ලෙස සකසන්න. පණිවිඩය ලබාදීම සඳහා එක් උත්සාහයක් පමණක් කළත්, ඔබේම පද්ධතිය තුළ ඇතැම් විට එකම පණිවිඩය workers දෙදෙනෙකුට ලැබිය හැක. ඇණවුමක මුදල පාරිභෝගිකයාට ප්රමාද වී බැර වීමට වඩා දෙවරක් බැර වීම බොහෝ බරපතළ දෝෂයකි.
ලියාපදිංචිය සහ රහස් යතුරු
කෝල්බැක් URL එක ලියාපදිංචි කිරීම, අත්සන් කළ පරීක්ෂණ ලබාදීමක් යැවීම සහ අත්සන් කිරීමේ රහස් යතුර අලුත් කිරීම යන සියල්ල සිදු කරන්නේ ඔබ ලොග් වූ රීසෙලර් පැනලය තුළිනි; පොදු API එක හරහා නොවේ. HTTPS අනිවාර්ය වන අතර, පුද්ගලික (private) ලිපින පිළිගන්නේ නැත.
රීසෙලර් පැනලයේ API ප්රවේශය විවෘත කරන්නඉල්ලීම් සීමා සහ දෝෂ හැසිරවීම
සීමාවන් ප්රසිද්ධ කර ඇති අතර, ඒවා එක් එක් ගිණුමට වෙනම අදාළ වේ. බලාත්මක කරන්නේ නිරන්තරයෙන් ඉදිරියට යන කාල කවුළුවක් (rolling window) අනුවයි. වැඩිපුර දත්ත කියවන කැටලොග් වැඩවලට ලැබෙන්නේ ඉහළම සීමාවයි. තත්ත්වය බලන endpoints හිතාමතාම තදින් සීමා කර ඇත්තේ, ඒවා නොනවත්වා poll කරන ලූපයක් ලෙස නොව, දත්ත ගළපා බැලීමට උපස්ථ මගක් ලෙස පවතින නිසයි.
| රවුට් | ඉල්ලීම් | කාල පරාසය | ගණන් කරන්නේ |
|---|---|---|---|
| GET /catalog/* (පහම) | 5000 | තත්පර 60 | ගිණුමකට |
| POST /orders/create | 5000 | තත්පර 60 | ගිණුමකට |
| GET /orders/:orderId | 3 | තත්පර 60 | ගිණුමකට + ඇණවුම් ID එකකට |
| POST /orders/batch | 2 | තත්පර 60 | ගිණුමකට |
| GET /orders | 2 | තත්පර 60 | ගිණුමකට |
| GET /account | 60 | තත්පර 60 | ගිණුමකට |
| POST /player/validate | ක්රීඩකයන් පරීක්ෂා කිරීමේ දෛනික සීමාව | පැය 24 | එක් එක් ගිණුමට වෙනම (මෙම සීමාව සඳහා X-RateLimit ශීර්ෂ ලැබෙන්නේ නැත) |
කැටලොග්, ඇණවුම් සහ ගිණුම් එන්ඩ්පොයින්ට් සෑම ප්රතිචාරයක් සමඟම X-RateLimit-Limit, X-RateLimit-Remaining සහ X-RateLimit-Reset හෙඩර් එවයි. ඒ නිසා නිසි ලෙස ලියූ ක්ලයන්ට් එකකට තමන් සිටින තත්ත්වය අනුමාන කිරීමට සිදු නොවේ. ඉතිරි ප්රමාණය පෙන්වන කවුන්ටරය නිරීක්ෂණය කරමින්, සීමාවට හසු වූ පසු නොව ඊට පෙරම වේගය අඩු කරන්න. ක්රීඩක තහවුරු කිරීම මීට ව්යතිරේකයකි. එය ක්රියා කරන්නේ ඔබේ දෛනික ක්රීඩක පරීක්ෂා කෝටාව මත වන අතර, X-RateLimit හෙඩර් කිසිවක් එවන්නේ නැත. එම කෝටාව වාර්තා කරන්නේ 429 ප්රතිචාරයේ බොඩි එක තුළයි.
HTTP/1.1 429 Too Many Requests
Retry-After: 45
X-RateLimit-Limit: 2
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1765000000
{
"success": false,
"error": {
"code": "RATE_LIMIT_EXCEEDED",
"message": "Rate limit exceeded. Try again after retry_after seconds.",
"action": "RETRY_LATER",
"retryable": true,
"retry_after": 45,
"details": {
"limit": 2,
"remaining": 0,
"retry_after": 45,
"window_seconds": 60
}
}
}මුලින්ම හමුවන දෝෂ සහ ඒවාට විසඳුම්
අසාර්ථක වන සෑම විටම HTTP status එක සමඟ ස්ථිර දෝෂ කේතයක් ලැබේ. අලුත් integration එකකට පළමු සතිය තුළ හමුවන්නේ මේවායි. එක් එක් දෝෂය අසල එය විසඳන වෙනස ද දක්වා ඇත.
| කේතය | HTTP තත්ත්ව කේතය | අර්ථය | විසඳන ආකාරය |
|---|---|---|---|
| INVALID_API_KEY | 401 | API key එක වලංගු නැතයැවූ API key එක පද්ධතියේ ඇති කිසිදු සක්රිය key එකකට නොගැළපේ. | key ID සහ secret නිවැරදි දැයි පරීක්ෂා කරන්න. අවශ්ය නම් API Access පැනලයෙන් key එක නැවත සාදාගන්න.action: FIX_INPUT · retryable: false · retry_after: null |
| IP_NOT_ALLOWED | 403 | IP ලිපිනය අවසර ලැයිස්තුවේ නැතඉල්ලීම පැමිණියේ ඔබේ API key allowlist එකේ නැති IP ලිපිනයකින්. | API Access පැනලයේ allowlist එකට ඔබේ සර්වර් IP එක එක් කරන්න, නැතහොත් IP සීමා ඉවත් කරන්න.action: FIX_INPUT · retryable: false · retry_after: null |
| MISSING_REQUIRED_FIELD | 400 | අවශ්ය field එකක් නැතඉල්ලීමේ body කොටසේ අවශ්ය ක්ෂේත්රයක් නැත. ක්රීඩක අවශ්යතා සම්බන්ධයෙන් නම්, නැති ක්ෂේත්රයේ නම details.field හි දැක්වේ. | එන්ඩ්පොයින්ට් ලේඛන සහ ක්රීඩක තොරතුරු සඳහා අවශ්ය ක්ෂේත්ර දැනගැනීමට GET /catalog/category/:categoryId/requirements බලන්න. ඉන්පසු අවශ්ය සියලුම ක්ෂේත්ර යවන්න.action: FIX_INPUT · retryable: false · retry_after: null |
| INVALID_UUID_FORMAT | 400 | UUID ආකෘතිය වලංගු නැතorder_id ලෙස එවූ ඇණවුම් හැඳුනුම වලංගු UUID ආකෘතියක් නොවේ. | ඕනෑම වලංගු UUID ආකෘතියක් භාවිත කළ හැකිය (v1, v4, v7 වැනි ඕනෑම අනුවාදයක්). ආකෘතිය: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. එනම්, ඉරි ලකුණු මඟින් වෙන් කළ අක්ෂර 8, 4, 4, 4 සහ 12 බැගින් වූ කොටස් පහකි.action: FIX_INPUT · retryable: false · retry_after: null |
| PLAYER_NOT_FOUND | 400 | ක්රීඩකයා හමු නොවීයමෙම Player ID එක නොපවතින බව ගේම් එක තහවුරු කර ඇත. මෙම දෝෂ කේතය ලැබෙන්නේ තහවුරු වූ පිළිතුරක් ඇති විට පමණි. ID එක පරීක්ෂා කළ නොහැකි විට ඒ වෙනුවට PLAYER_CHECK_UNAVAILABLE ලැබේ. | Player ID එක නිවැරදිදැයි පරීක්ෂා කරන්න. මෙම ගේම් එකට zone_id එකක් අවශ්යදැයි ද බලන්න.action: FIX_INPUT · retryable: false · retry_after: null |
| PLAYER_CHECK_UNAVAILABLE | 503 | මෙම ගේම් එකේ Player ID දැන් තහවුරු කළ නොහැකමේ වන විට මෙම ගේම් එකේ Player ID පරීක්ෂා කළ නොහැක. මෙයින් අදහස් වන්නේ Player ID එක ප්රතික්ෂේප වූ බව නොවේ. | retry_after හි ඇති තත්පර ගණනට පසු එම ඉල්ලීමම නැවත යවන්න. ID එක වැරදි බව ඔබේ පාරිභෝගිකයාට නොකියන්න.action: RETRY_LATER · retryable: true · retry_after: 60 |
| REGION_MISMATCH | 400 | මෙම ක්රීඩකයාගේ කලාපයට මෙම නිෂ්පාදනය ලබාදිය නොහැකමෙම නිෂ්පාදනය ලබාදිය නොහැකි කලාපයකට ක්රීඩකයා අයත් වේ. දෝෂය සමඟ player_region සහ player_name ද ලැබේ. | ක්රීඩකයාගේ කලාපයට අදාළ නිෂ්පාදනය තෝරන්න.action: CHOOSE_OTHER · retryable: false · retry_after: null |
| INSUFFICIENT_BALANCE | 400 | වොලට් ශේෂය ප්රමාණවත් නැතමෙම ඇණවුම සම්පූර්ණ කිරීමට ඔබේ වොලට් එකේ ප්රමාණවත් මුදල් නැත. | ඇණවුම කිරීමට පෙර Reload පිටුවෙන් වොලට් එක ටොප් අප් කරන්න.action: TOP_UP · retryable: false · retry_after: null |
| OUT_OF_STOCK | 400 | නිෂ්පාදනයේ තොගය අවසන්ඉල්ලූ නිෂ්පාදනයේ තොගය දැනට අවසන් වී ඇත. | පසුව නැවත උත්සාහ කරන්න, නැතහොත් වෙනත් නිෂ්පාදනයක් තෝරන්න.action: RETRY_LATER · retryable: true · retry_after: null |
| PRODUCT_UNAVAILABLE | 409 | මෙම නිෂ්පාදනය තාවකාලිකව ලබාගත නොහැකනිෂ්පාදනය පවතී, නමුත් දැනට එය විකිණිය නොහැක. | ටික වේලාවකට පසු නැවත උත්සාහ කරන්න, නැතහොත් වෙනත් නිෂ්පාදනයක් තෝරන්න.action: RETRY_LATER · retryable: true · retry_after: null |
| DUPLICATE_ORDER | 409 | ඇණවුම් ID එක දැනටමත් භාවිත කර ඇතමෙම UUID එක සහිත ඇණවුමක් දැනටමත් ඇත. මෙය එකම ඇණවුම දෙවරක් සෑදීම වළක්වන idempotency ආරක්ෂාවකි. | නව ඇණවුමක් සඳහා නව UUID එකක් සාදන්න. නැවත උත්සාහයකදී මෙය ලැබුණොත්, පළමු ඉල්ලීම දැනටමත් පිළිගෙන ඇති බවයි: තවත් ඇණවුමක් සාදනවා වෙනුවට GET /orders/{orderId} මඟින් එම ඇණවුම කියවන්න.action: CHECK_ORDER · retryable: false · retry_after: null |
| PRICE_INCREASED | 400 | මිල අපේක්ෂිත මට්ටම ඉක්මවා වැඩි වී ඇතදැනට පවතින ඒකක මිල, ඔබ ඉල්ලීමේ සඳහන් කළ expected_unit_price අගයට වඩා වැඩියි. | පළමුව, අදාළ උප කාණ්ඩයේ නවතම මිල දැන ගැනීම සඳහා GET /catalog/subcategory/:id/price ඉල්ලීම යවන්න. ඉන්පසු ඔබේ ඇණවුම් ඉල්ලීමේ ඇති expected_unit_price අගය, ලැබුණු එම නව මිලට ගැළපෙන ලෙස යාවත්කාලීන කරන්න.action: FIX_INPUT · retryable: false · retry_after: null |
| RATE_LIMIT_EXCEEDED | 429 | ඉල්ලීම් සීමාව ඉක්මවා ඇතඔබ මෙම එන්ඩ්පොයින්ට් එකට නියමිත ඉල්ලීම් සීමාව ඉක්මවා ඇත. කැටලොග්, ඇණවුම් සහ ගිණුම් යන විනාඩි සීමා කොටස්වලට අයත් එන්ඩ්පොයින්ට් සෑම ප්රතිචාරයක් සමඟම X-RateLimit-Limit, X-RateLimit-Remaining සහ X-RateLimit-Reset යන හෙඩර් යවයි. ඊට අමතරව, ප්රතිචාරයේ details කොටසේද limit, remaining (0), retry_after සහ window_seconds යන අගයන් එලෙසම නැවත සඳහන් කර ඇත. POST /player/validate එන්ඩ්පොයින්ට් එක සඳහා නම් මෙම විනාඩි සීමා අදාළ නොවේ. එහි ඉල්ලීම් ගණනය වන්නේ ඒ වෙනුවට ඔබේ දෛනික ක්රීඩක පරීක්ෂා කෝටාවට අනුවයි. එය ඉහත සඳහන් හෙඩර් කිසිවක් නොයවයි. සීමාව ඉක්මවූ විට ලැබෙන 429 ප්රතිචාරයේදී limit, current, remaining, reset_at සහ reset_in_seconds යන අගයන් සියල්ල error වස්තුව ඇතුළත ලැබේ. අවස්ථා දෙකේදීම, ඔබ නැවත උත්සාහ කිරීමට පෙර රැඳී සිටිය යුතු තත්පර ගණන error.retry_after සහ Retry-After හෙඩරය යන දෙකෙහිම සඳහන් වේ. | නැවත උත්සාහ කිරීමට පෙර retry_after අගයේ හෝ Retry-After හෙඩරයේ සඳහන් තත්පර ගණන ගත වන තුරු රැඳී සිටින්න. විනාඩි සීමා සහිත එන්ඩ්පොයින්ට්වලදී X-RateLimit-Remaining අගය නිරීක්ෂණය කරන්න. එවිට සීමාවට ළඟා වීමම වළක්වා ගත හැක.action: RETRY_LATER · retryable: true · retry_after: යළි සැකසීමට ඉතිරි තත්පර |
| INTERNAL_ERROR | 500 | සර්වර් එකේ අභ්යන්තර දෝෂයක්සර්වර් එකේ අනපේක්ෂිත දෝෂයක් ඇති විය. | retry_after තත්පර ගත වූ පසු ඉල්ලීම නැවත යවන්න. POST /orders/create සඳහා එම order_id එකම නැවත භාවිත කරන්න. එවිට එකම ඇණවුම කිසිවිටෙක දෙවරක් සෑදෙන්නේ නැත. ගැටලුව දිගටම පවතී නම් සපෝට් කණ්ඩායම අමතන්න.action: RETRY_LATER · retryable: true · retry_after: 30 |
ඒකාබද්ධ කිරීම ගැන ප්රශ්න සහ පිළිතුරු
මෙය සම්බන්ධ කරන අතරතුර සංවර්ධකයන් සැබවින්ම අසන ප්රශ්න: සත්යාපනය, නැවත උත්සාහ කිරීම්, idempotency, ඉල්ලීම් සීමා කිරීම, කෝල්බැක් සහ දෝෂ හැසිරවීම.
රීසෙලර් API එක requests සත්යාපනය කරන්නේ කෙසේද?
එක් HTTP හෙඩරයක් පමණක් ප්රමාණවත්: Authorization: Bearer <keyId>.<secret>. මෙම යතුරු යුගලය නිකුත් කරන්නේ ඔබේ රීසෙලර් පැනලයේ API Access පිටුවෙනි. රහස් යතුර පෙන්වන්නේ එය සාදන මොහොතේ එක් වරක් පමණි. සෑම ඉල්ලීමකදීම සර්වර් එක HMAC පරීක්ෂාවකින් එය තහවුරු කරයි. OAuth රීඩිරෙක්ට් එකක්, සෙෂන් කුකියක් හෝ රිෆ්රෙෂ් කළ යුතු ටෝකනයක් නැත. ඒ නිසා පළමු ඉල්ලීමටත් ඊට පසු එන සෑම ඉල්ලීමකටත් එකම හෙඩරය ක්රියා කරයි.
මගේ ක්ලයන්ට් එක යොමු කළ යුත්තේ කුමන මූලික URL ලිපිනයට සහ කුමන API අනුවාදයටද?
ඇත්තේ එක් මූලික URL එකක් පමණි, එය සජීවී එකයි. ගොඩනගා පසුව මාරු කිරීමට වෙනම සෑන්ඩ්බොක්ස් හෝස්ට් එකක් නැත. ක්ලයන්ට් එක ඉහත දක්වා ඇති v1 මූලික URL එකට යොමු කර, සෑම ඉල්ලීමකම Authorization: Bearer <keyId>.<secret> යවන්න. වෙන කිසිවක් කිරීමට පෙර GET /account ඉල්ලීමෙන් ගිණුම කියවා, යතුර සහ හෙඩරයේ ආකෘතිය නිවැරදි බව තහවුරු කරගන්න. මුදල් චලනය කරන එකම ඉල්ලීම POST /orders/create වේ. එය අවසානයට තබා, ඔබේ කුඩාම අගයේ පැකේජයෙන් අත්හදා බලන්න. ක්ලයන්ට් එක තවමත් පරීක්ෂා කරමින් ස්ථාවර කරන අතරතුර, එය සමඟ expected_unit_price ලෙස බලාපොරොත්තු වන ඒකක මිලද යවන්න.
POST /orders/create ඉල්ලීමේදී, එකම ඇණවුම දෙවරක් සෑදීම වළක්වන යතුර යවන්නේ කුමන ක්ෂේත්රයෙන්ද?
order_id field එකේ. එය client පැත්තේ ඔබ සාදා create body එකේ යවන UUID එකක්. දැනටමත් පවතින order_id එකක් සමඟ create එක නැවත යැව්වොත්, API එක දෙවන ඇණවුමක් විවෘත නොකර HTTP 409 සමඟ DUPLICATE_ORDER ලෙස පිළිතුරු දෙනවා. ඒ නිසා නැවත උත්සාහ කිරීමකින් කිසිවිටෙක දෙවරක් මුදල් අය වන්නේ නැහැ. මුල් ඇණවුම GET /orders/:orderId මගින් කියවන්න. පළමු උත්සාහයට පෙරම UUID එක සාදා ගබඩා කරගන්න. Timeout එකකින් පසු සාදන UUID එකක් retry key එකක් නොව අලුත් key එකක්. එකම දේ අදහස් කළ order_id අගයන් දෙකක් සර්වර් එක එකට ඒකාබද්ධ කරන්නේ නැහැ.
මගේ ඉල්ලීම ටයිම්අවුට් විය. ඇණවුම සෑදී තිබේද?
අනුමාන කරනවා වෙනුවට status එක කියවා දැනගන්න. ඔබ යැවූ UUID එකම භාවිතයෙන් GET /orders/:orderId call කරන්න. ඇණවුම ලැබෙනවා නම්, timeout එක සිදු වූයේ ඇණවුම පිළිගත් පසුවයි, එවිට නැවත යවන්න එපා. ORDER_NOT_FOUND ලැබුණොත් කිසිදු මුදලක් අය වී නැහැ. එවිට එම UUID එකම සමඟ create request එක නැවත යැවීම ආරක්ෂිතයි.
වෙබ්හුක් කෝල්බැක් එකක අත්සන තහවුරු කරගන්නේ කෙසේද?
ලැබුණු ඉල්ලීමේ අමු බොඩි එක මත HMAC නැවත ගණනය කර, එය X-Shop2Topup-Signature හෙඩරය සමඟ සසඳන්න. එම හෙඩරයේ අගය ඇත්තේ sha256=<hex> ආකාරයෙනි. ඔබට ලැබුණු බයිට් එලෙසම ඔබේ වෙබ්හුක් රහස් යතුරෙන් HMAC-SHA256 කර, ඉදිරියෙන් sha256= එකතු කර, timing-safe සැසඳීමකින් පරීක්ෂා කරන්න. නැවත සීරියලයිස් කළ JSON වස්තුවක් සමඟ කිසිදා සසඳන්න එපා. පාර්ස් කර නැවත ස්ට්රින්ග් කිරීමේදී බයිට් වෙනස් වන නිසා එවැනි සැසඳීමක් කිසිවිටෙක ගැළපෙන්නේ නැත. නොගැළපෙන ඉල්ලීමක් 401 සමඟ ප්රතික්ෂේප කරන්න. වලංගු වෙබ්හුක් ලබාදීමකට තත්පර 10ක් ඇතුළත 200 ලෙස පිළිතුරු දී, පියවීමේ වැඩ පසුව ඔබේම පෝලිමක කරන්න.
Rate limit එකට ළඟා වූ විට කුමක් වෙනවාද?
HTTP 429 ප්රතිචාරයක් RATE_LIMIT_EXCEEDED දෝෂ කේතය සහ Retry-After හෙඩරය සමඟ ලැබේ. ප්රතිචාරයේ බොඩි එකේ retry_after හි එම අගයම නැවත දැක්වෙන අතර, limit, remaining සහ window_seconds ද එකතු වේ. හරියටම එම තත්පර ගණන බලා සිට එක් වරක් නැවත උත්සාහ කරන්න. වහාම නැවත උත්සාහ නොකරන්න. එකම ඉල්ලීම යතුරු කිහිපයක් අතර බෙදා යැවීමත් එපා, මන්ද කවුන්ටරය ගණනය වන්නේ සම්බන්ධතාවයට නොව ගිණුමටයි.
ක්රීඩක තහවුරු කිරීමේ POST /player/validate ඉල්ලීමේ ප්රතිචාරයට ඇතුළත් වන්නේ කුමන ක්ෂේත්රද?
Response එකේ data object එක තුළ player_name ලැබෙනවා. ගේම් එක ලබා දෙන අවස්ථාවල zone_id සහ region ද ලැබෙනවා. ඇණවුම සාදන විටම ක්රීඩකයා සොයා කලාපය පරීක්ෂා කරන අතර, වෙනත් කලාපයක ගිණුමකට කරන උත්සාහයක් වොලට් එකෙන් මුදල් අඩු වීමට පෙරම REGION_MISMATCH (HTTP 400) සමඟ ප්රතික්ෂේප වෙනවා. ඒ නිසා ඔබේ ශේෂය ආරක්ෂා කරන්නේ මේ call එක නොවේ. ගැනුම්කරුට තමන් ටොප් අප් කරන්නට යන ගිණුම පෙන්වීමට සහ ඇණවුම තහවුරු කිරීමට පෙර වැරදියට ටයිප් කළ ID එකක් හඳුනා ගැනීමට ඇති එකම ප්රායෝගික ක්රමය player_name නැවත කියවීමයි. එම නිසයි මෙය call කළ යුත්තේ. නම සැමවිටම ලැබෙන්නේ ගේම් එකෙන්, ගැනුම්කරු ටයිප් කළ කිසිවකින් නොවේ.
requirements ප්රතිචාරයේ දත්ත මගේ ඇණවුම් පේලෝඩ් එකට ගළපන්නේ කෙසේද?
field_name අනුව සකසන්න: GET /catalog/category/:categoryId/requirements මගින් ලැබෙන සෑම ඇතුළත් කිරීමක්ම, POST /orders/create වෙත යවන requirements වස්තුවේ එක් ගුණාංගයක් බවට පත් වේ. සෑම ඇතුළත් කිරීමකම data_type ද ඇත. එමගින් ඔබේ ෆෝම් එකට පෙන්විය යුත්තේ කුමක්ද යන්නත්, සර්වර් එකට අගය පරිවර්තනය කළ යුත්තේ කුමන වර්ගයටද යන්නත් දැනගත හැක. single_select සහ multi_select ඇතුළත් කිරීම් ඒවාට අවසර ඇති අගයන් සමඟම එයි. නිදහස් ටයිප් කිරීමේ කොටුවක් වෙනුවට එම අගයන් තෝරා ගැනීමට දෙන්න. මෙම ලැයිස්තුව සෑම ඇණවුමකටම කියවනවා වෙනුවට කැටගරිය අනුව කෑෂ් කර තබාගෙන, ඇණවුම් සෑදීමේ ඉල්ලීමක් MISSING_REQUIRED_FIELD සමඟ ආපසු ආ විට නැවත කියවන්න.
PRICE_INCREASED (මිල ඉහළ ගොස් ඇත) ප්රතිචාරයක් ලැබුණු විට මගේ ක්ලයන්ට් එක කළ යුත්තේ කුමක්ද?
මිල නැවත කියවා, තීරණය කර, ඉන්පසු නැවත යවන්න. එකම ඉල්ලීම් බොඩි එක කිසිදා නැවත යවන්න එපා. PRICE_INCREASED (HTTP 400) යනු සජීවී ඒකක මිල ඔබ යැවූ expected_unit_price අගයට වඩා ඉහළ බවයි. එබැවින් ඇණවුම් සෑදීමේ ඉල්ලීම ප්රතික්ෂේප වූ අතර කිසිදු මුදලක් අය කර නැත. දෝෂ විස්තරවල expected_unit_price සහ current_unit_price යන දෙකම ඇති අතර, පැරණි අගයම සමඟ නොසිතා නැවත උත්සාහ කිරීම සෑම වරම ප්රතික්ෂේප වේ. GET /catalog/subcategory/:itemId/price මගින් මිල කියවා, නව අගය ඔබට තවමත් ගැළපේදැයි තීරණය කරන්න. ඉන්පසු යාවත්කාලීන expected_unit_price සමඟ, එකම order_id භාවිත කර ඇණවුම නැවත යවන්න. ප්රතික්ෂේප වූ උත්සාහයකින් එය භාවිත වී නැත. expected_unit_price ඉවත් කළහොත් මෙම ආරක්ෂාව සම්පූර්ණයෙන්ම අක්රිය වේ. ස්වයංක්රීය ඒකාබද්ධ කිරීමකට එය අවශ්ය වන්නේ ඉතා කලාතුරකිනි.
කොටසක් පමණක් ලබාදුන් ඇණවුමක් order response එකේ දිස්වන්නේ කෙසේද?
ඇණවුමේ status අගය partial ලෙස ලැබෙන අතර, බෙදීම sub_transaction_summary තුළ පැහැදිලිව දක්වා ඇත. එම සාරාංශය ඒකක ගණන් කරන්නේ සම්පූර්ණයි (completed), මුදල් ආපසු ගෙවූ (refunded) සහ පොරොත්තුවෙන් (pending) යන තත්ත්ව තුනට අනුවයි. මේ තුනේ එකතුව සැමවිටම total අගයට සමාන වේ. sub_transactions තුළ සෑම ඒකකයක්ම තමන්ගේම තත්ත්වය සමඟ වෙන වෙනම දැක්වේ. තවමත් ලබා දී හෝ මුදල් ආපසු ගෙවා නැති ඒකකයක් පොරොත්තුවෙන් තත්ත්වයේම පවතී. පොරොත්තුවෙන් යනු අවසාන තත්ත්වයක් නොවන බැවින් දිගටම බලා සිටින්න. සම්පූර්ණයි, partial සහ මුදල් ආපසු ගෙවූ යන තත්ත්ව අවසාන ලෙස සලකන්න. අසාර්ථකයි (failed), සැකසෙමින් (processing) සහ නැවත උත්සාහ කරමින් (retrying) යන ගණන් තබා ඇත්තේ අනුකූලතාව සඳහා පමණක් වන අතර, ඒවා සැමවිටම 0 වේ. මේ සාරාංශයම order.completed සහ order.refunded callback දෙකෙහිම ඇතුළත් වේ. ඒ නිසා තහවුරු කළ පණිවිඩයක් ලැබුණු විට, නැවත විමසීමකින් තොරවම ගනුදෙනුව නිරවුල් කළ හැක.
allowlist එකෙන් පිටත ලිපිනයකින් එන ඉල්ලීමකට ලැබෙන ප්රතිචාරය කුමක්ද?
කිසිදු ව්යාපාරික තර්කනයක් ක්රියාත්මක වීමට පෙරම, IP_NOT_ALLOWED කේතය සහිත HTTP 403 ප්රතිචාරයක් ලැබේ. key එකට හිස් නොවන IP අවසර ලැයිස්තුවක් (allowlist) ඇති සෑම විටම මෙම පරීක්ෂාව ක්රියාත්මක වේ. එබැවින් key එකක් කාන්දු වුවත්, ඔබේම පිටතට යන ලිපින හැර වෙනත් කිසිම තැනක එය වැඩ කරන්නේ නැත. පණිවිඩයේ පෙළ අනුව නොව error.code අනුව තීරණ ගන්න. සජීවී පද්ධතියේ හදිසියේ IP_NOT_ALLOWED ලැබුණොත්, එය key එක කැඩී ඇති ලකුණක් නොව පිටතට යන ලිපිනය වෙනස් වී ඇති ලකුණක් ලෙස සලකන්න. උදාහරණයක් ලෙස අලුත් NAT gateway එකක් හෝ worker subnet එකක් එයට හේතු විය හැක. ඔබේ පිටතට යන ලිපිනය සැබවින්ම ස්ථාවර නැත්නම් පමණක් අවසර ලැයිස්තුව හිස්ව තබන්න.
ඇණවුමක් සම්පූර්ණ වීමට කොපමණ කාලයක් ගතවේද?
ඇණවුම සම්පූර්ණ වන්නේ පසුව වෙනම ක්රියාවලියකින් බව සලකන්න. එය ක්ෂණිකව සම්පූර්ණ වේ යැයි නොසලකන්න. ඇණවුම පිළිගෙන වොලට් ශේෂයෙන් මුදල අඩු කළ වහාම POST /orders/create ප්රතිචාරය ලබා දෙයි. ඒ අවස්ථාවේ තත්ත්වය සාමාන්යයෙන් pending (පොරොත්තුවෙන්) වේ. ඉන්පසු වෙනම පසුබිම් ක්රියාවලි මගින් ඇණවුම ඉටු කරන අතර, අවසාන තත්ත්වය webhook මගින් හෝ ඊළඟ වර තත්ත්වය විමසන විට ලැබේ. පාරිභෝගිකයාට ප්රතිචාර දෙන HTTP ඉල්ලීම අවසාන තත්ත්වය ලැබෙන තුරු රඳවා තබන්න එපා. ඉල්ලීම පිළිගෙන පාරිභෝගිකයාට පිළිතුරු දෙන්න. අවසාන තත්ත්වයට අනුව අවශ්ය කටයුතු එම HTTP ඉල්ලීමෙන් වෙන්ව සිදු කරන්න.
ගිණුමක් සාදන්න, key එකක් ලබාගන්න, live වන්න
ලියාපදිංචි වීමේ සිට API එක call කිරීම දක්වා අනුමැතියක් බලා සිටින පෝලිමක් හෝ පොරොත්තු කාලයක් නැත. රීසෙලර් ගිණුම සාදා, API Access පිටුවේ key එකක් සාදන්න, වොලට් එකට මුදල් දමන්න. ඔබේ පළමු ඇණවුම එදිනම යැවිය හැක.
ඔබ මෙම ව්යාපෘතියේ developer නොවේ නම්, ව්යාපාරික කරුණු මෙතැනින් කියවන්න: SHOP2TOPUP රීසෙලර් වැඩසටහන් පිටුව.