Maombi ya uthibitishaji usio na kikomo: kuepuka hundi zinazorudiwa na ada zinazorudiwa

Ili kujaribu tena ombi la uthibitishaji kwa usalama, tuma hilo hilometadata.requestIdkila wakati unapojaribu tena. Toden vitafuniorequestIdkama ufunguo wako wa kutojitambua: ikiwa ombi litafika narequestIdshirika lako tayari limetumia, API Inarudisha uthibitishaji uliopo badala ya kuunda ule wa pili, na hutatozwa mara mbili.

Sehemu hiyo moja inakulinda tu ikiwa unaishughulikia kwa usahihi.requestIdLazima itolewe mara moja kwa kila uthibitisho wa kimantiki, ihifadhiwe kabla ya jaribio la kwanza, na itumiwe tena kihalisi. Itengeneze ndani ya mzunguko wako wa kujaribu tena na kila jaribio linakuwa uthibitisho mpya kabisa. Sehemu iliyobaki ya makala haya inashughulikia wapi pa kuiunda, ni majibu gani ya kujaribu tena, na ni "kushindwa" gani sio kushindwa kabisa.

Ni nini kitakachotokea bila ubinafsi?

Kesi ya kawaida ni muda wa mwisho baada ya mafanikio. Seva yako hutumaPOST /api/kyc/verify, API Inakubali na kuweka uthibitishaji kwenye foleni, na jibu linapotea njiani kurudi: muunganisho wa simu uliopungua, muda wa kusawazisha mzigo kuisha, na kuanzisha upya kwa pod. Kwa upande wako, ombi lilishindwa. Kwa upande wetu, lilifanikiwa.

Ikiwa msimbo wako utajaribu tena na kitambulisho kipya, mfumo huona ombi jipya na kuunda uthibitishaji wa pili. Katika Uzalishaji, kila uthibitishaji uliokamilika hutozwa kwenye salio lako la mkopo, kulingana na nyaraka za mazingira (hufunguka kwenye kichupo kipya) , kwa hivyo jibu lililopotea limekugharimu hundi ya pili. Pia huacha vitambulisho viwili vya uthibitishaji vilivyounganishwa na mwombaji mmoja, na upatanisho wako sasa unapaswa kuamua ni upi halisi.

Pamoja na hayo hayorequestId, jaribio jipya hurejesha uthibitishaji wa awali, na jibu lililopotea haligharimu chochote.

RequestId inafanyaje kazi kwenye sehemu ya mwisho ya kuthibitisha?

Inaishi ndani ya ombimetadatakitu. Kutoka kwa marejeleo ya uthibitishaji wa uundaji (hufunguka kwenye kichupo kipya) :

{
  "country": "NG",
  "idType": "bvn",
  "idNumber": "12345678901",
  "externalUserId": "user_42",
  "metadata": { "requestId": "order_1001", "loanId": "loan_20191" }
}

Marejesho ya uwasilishaji wa kwanza202 Accepted:

{
  "verificationId": "ver_01j9...",
  "status": "processing",
  "externalUserId": "user_42",
  "metadata": { "loanId": "loan_20191" }
}

Uwasilishaji wa baadaye wenye umbo lile lilerequestIdhurejesha uthibitisho huo, katika hali yoyote ile ambayo umefikia, kwa mfano{ "verificationId": "ver_01j9...", "status": "approved" }.externalUserIdna metadata yako inarudi kama ilivyohifadhiwa, kwa hivyo jaribio jipya na ile ya asili inakubaliana.

Funguo zimeelekezwa kwa shirika lako. IkiwarequestIdinagongana na moja ya shirika lingine, API marejesho403na{ "error": "Forbidden" }badala ya kufichua chochote kuhusu uthibitisho huo.

Unapaswa kutoa wapi ombi la kitambulisho (requestId)?

Kutoka kwenye rekodi yako mwenyewe, na kabla ya kutuma chochote. Muundo unaodumu:

1. Mteja anapoanza kuthibitisha utambulisho, tengeneza safu katika hifadhidata yako mwenyewe kwa jaribio hilo (ombi, hatua ya kujiunga, mkopo).

2. PatarequestIdkutoka safu hiyo, kwa mfanokyc-application-8841, na uihifadhi kwenye safu.

3. Tuma ombi lenye thamani hiyo iliyohifadhiwa.

4. Unapojaribu tena, soma thamani kutoka kwenye safu mlalo. Usiwahi kukokotoa mpya.

Sheria tatu zinafuata:

• Usitumie njia isiyo ya kawaida UUID zinazozalishwa kwa kila HTTP simu. Hiyo ni kitambulisho cha kipekee cha simu, ambacho ni kinyume cha kile unachohitaji.

• Nafasi ya majina. Utupu1001kuna uwezekano wa kugongana na rekodi zako zingine baada ya muda, na mgongano wa shirika mtambuka unarudi403Kiambishi awali kama vilekyc-application-hufanya thamani hiyo kuwa wazi.

• Tengeneza mpya kwa ajili ya uthibitishaji mpya kabisa. Ikiwa mteja amekataliwa na ukaamua anaweza kuanza tena kuanzia mwanzo, huo ni uthibitishaji mpya wa kimantiki na mpyarequestIdKutumia tena ile ya zamani kungerudisha tu uthibitishaji uliokataliwa.

Ikiwa mkaguzi atarudisha uthibitisho ili mwombaji aweze kufanya upya hatua kadhaa, huhitaji mpyarequestIdkabisa. Uthibitisho unaotumwa au kuthibitishwa tena huhifadhi kitambulisho chake, na uwasilishaji upya huonekana kama mpyaattemptjuu yake, kama marejeleo ya matokeo ya uthibitishaji (hufunguka kwenye kichupo kipya) yanavyoelezea.

Wakati SDK inawasilisha kwa ajili yako

Miunganisho mingi haitoi simu/verifymoja kwa moja. Wavuti, React Native na Flutter SDK hupiga simu wakati mwombaji anapobonyeza tuma. Wanakubalimetadatana yakorequestId(metadata={{ requestId: "order_1001" }}katika React Native,metadata: {'requestId': 'order_1001'}katika Flutter), kwa hivyo kanuni hiyo hiyo inatumika: pitisha thamani inayotokana na rekodi yako mwenyewe, sio moja inayozalishwa mpya kila wakati skrini inapowekwa.

Ni majibu gani unapaswa kujaribu tena?

Nyaraka za makosa (hufunguka kwenye kichupo kipya) ziko wazi, na zinaelekezwa kwenye jedwali fupi.

Kikomo kilichoandikwa ni maombi 100 kwa kila dakika 15 kwa kila mteja, pamoja naRateLimit-Limit,RateLimit-RemainingnaRateLimit-Resetvichwa vya habari kwenye majibu. KusomaRateLimit-RemainingHuruhusu kazi ya wingi kupungua kabla haijakataliwa, badala ya baada ya hapo. Ukurasa wa mipaka ya viwango (hufunguka kwenye kichupo kipya) unabainisha kuwa mipaka inaweza kutofautiana kati ya Sandbox na Uzalishaji na inaweza kubadilishwa kwa akaunti yako.

Kitanzi cha kujaribu tena salama kinaonekanaje?

Toleo dogo la Node.js, kwa kutumia mfumo wa kimataifafetchMwili hupangwa mara moja mfululizo, nje ya kitanzi, kwa hivyo kila jaribio hutuma baiti zinazofanana zenye sawarequestId.

const VERIFY_URL = 'https://api.toden.co/api/kyc/verify';
const RETRYABLE = new Set([429, 502, 503, 504]);
const sleep = (ms) => new Promise((resolve) => setTimeout(resolve, ms));
const backoff = (attempt) => Math.min(30_000, 500 * 2 ** attempt) * (0.5 + Math.random());

export async function submitVerification(body, apiKey, maxAttempts = 5) {
  if (!body.metadata?.requestId) throw new Error('metadata.requestId is required');
  const payload = JSON.stringify(body);

  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    let res;
    try {
      res = await fetch(VERIFY_URL, {
        method: 'POST',
        headers: { Authorization: `Bearer ${apiKey}`, 'Content-Type': 'application/json' },
        body: payload,
      });
    } catch (networkError) {
      if (attempt === maxAttempts) throw networkError;
      await sleep(backoff(attempt));
      continue;
    }

    if (res.ok) return res.json(); // 202 for a new verification, or the existing one on a replay

    if (!RETRYABLE.has(res.status) || attempt === maxAttempts) {
      const detail = await res.json().catch(() => ({}));
      throw Object.assign(new Error(detail.error ?? `HTTP ${res.status}`), { status: res.status, detail });
    }

    const resetSeconds = Number(res.headers.get('RateLimit-Reset'));
    await sleep(res.status === 429 && resetSeconds > 0 ? resetSeconds * 1000 : backoff(attempt));
  }
}

Kumbuka kile ambacho hakipo: hakuna kujaribu tena400,401au403, na hakuna kitambulisho kipya popote. Mpigaji simu hutoarequestIdtayari imehifadhiwa.

Je, uthibitisho ulioshindwa ni jambo la kujaribu tena?

Hapana, na kuchanganya hayo mawili ni chanzo cha kawaida cha nakala rudufu.202inamaanisha tu kwamba ombi lilikuwa kwenye foleni. Uthibitishaji bado unaweza kuishadeclinedkwa sababu uso haukulingana, au kwa sababu kitambulisho hakikupatikana kwenye hifadhidata ya serikali. Hayo ni matokeo yanayotolewa na webhook au kwa kura, kila moja ikiwa nareasonna zizireasonCode. Hawako HTTP makosa.

Ikiwa mantiki yako ya kujaribu tena itaangalia matokeo na kuwasilisha tena wakati imepungua, itarejeshewa uthibitisho uleule uliokataliwa (sawarequestId) au kuunda uthibitishaji wa pili, uliolipwa wa ingizo lile lile baya (mpyarequestIdHakuna kinachosaidia. Tawi kwenyereasonCodebadala yake: omba picha mpya kwenyedocument_blurry, kwa nambari iliyosahihishwa kwenyeidentity_not_found, na kumtuma mtu huyo kupitia uthibitishaji mpya au uliorekebishwa kimakusudi.

Je, upande wa wavuti unahitaji idempotency pia?

Ndiyo. Uwasilishaji uleule wa webhook unaweza kufika zaidi ya mara moja, kwa sababu uwasilishaji hujaribiwa tena hadi sehemu yako ya mwisho itambue. Nyaraka za webhooks (hufunguka kwenye kichupo kipya) zinasema toa uwasilishaji kwenyeX-Myaza-Deliverykichwa cha habari, au kwenyeverificationId. Andika kile ulichokishughulikia na ufanye kidhibiti kisifanye kazi mara ya pili. Kutuma bila malipo na kupokea bila malipo pamoja ndivyo vinavyofanya mtiririko utokee mara moja tu kutoka kwa mtazamo wa mteja wako.

Orodha ya ukaguzi

• MojarequestIdkwa kila uthibitisho wa kimantiki, unaotokana na rekodi yako mwenyewe na nafasi ya majina.

• Imehifadhiwa kabla ya jaribio la kwanza; soma tena, haijatengenezwa tena, unapojaribu tena.

• Imepita kupitia SDK 'smetadatawakati SDK inawasilisha kwa ajili yako.

• Majaribio tena yamewashwa429,502,503,504na hitilafu za mtandao pekee, zikiwa zimezimwa naRateLimit-Resetthamani.

• Matokeo kama viledeclinedkushughulikiwa nareasonCode, kamwe kwa kuwasilisha tena.

• Kidhibiti cha wavuti kimetolewa kwenyeX-Myaza-DeliveryauverificationId.

Mkataba kamili wa ombi uko kwenye marejeleo ya uthibitishaji wa uundaji (hufunguka kwenye kichupo kipya) , na kitovu cha msanidi programu huunganisha sehemu iliyobaki ya API .