Përdorni një markë mesazhesh që i përket llogarisë
Përdorni një llogari API të aktivizuar përmes HTTPS nga një adresë IP burimore e lejuar. Mbështetet autentikimi Basic dhe Bearer. Identifikuesi i markës duhet t'i përkasë asaj llogarie. Mbajini konfidencialë tokenët e ofruesit, të dhënat e identitetit të markës dhe raportet e kthyera.
Përdorni një rezultat ekzistues nga ofruesi
Përdorni PUT për të lidhur një rezultat ekzistues verifikimi nga një ofrues i mbështetur me markën tuaj. Kjo nuk porosit një kontroll të ri. Merrni identifikuesin e saktë të transaksionit të ofruesit dhe çdo token konfirmimi drejtpërdrejt nga ai ofrues dhe sigurohuni që raporti t'i përkasë të njëjtit identitet biznesi.
AUTHPLUS nuk e mbështet këtë rrjedhë pune për importin. Rregullat e përputhjes specifike për ofruesin vazhdojnë të zbatohen; një kërkesë importi nuk i heq ato dhe as nuk garanton përmbushjen e kushteve për çdo rast përdorimi të fushatave.
Përgatitni importin
| Fusha | Vlera |
|---|---|
| evpId | Identifikuesi i ofruesit të mbështetur, 1–10 karaktere. |
| vettingId | Identifikuesi real i transaksionit të verifikimit të ofruesit, deri në 255 karaktere. Mos e zëvendësoni me identifikuesin e markës dhe mos shpikni një identifikues. |
| vettingToken | Tokeni i konfirmimit kur kërkohet nga ofruesi, deri në 65535 karaktere. Trajtojeni si sekret dhe mos e përfshini kur ofruesi nuk e kërkon. |
Krijoni vetting-import.json duke përdorur vlerat reale të ofruesit. Mos dërgoni fushat e pikëzimit, statusit ose vulës kohore që jepen vetëm në përgjigje, sikur ato të mund ta ndryshonin rezultatin.
Importojeni rezultatin vetëm një herë
curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
--request PUT \
--header 'Content-Type: application/json' \
--header "Idempotency-Key: $IDEMPOTENCY_KEY" \
--data-binary @vetting-import.json \
"https://api.multitel.net/tcr/v2/brand/$BRAND_ID/externalVetting"Kuptoni tarifimet ekzistuese
Ky ndërmjetës nuk e regjistron një rezultat të sapoimportuar si porosi të re me pagesë. Kjo nuk anulon një kontroll të porositur më parë: kur për të njëjtin vettingId ekziston tashmë një porosi në pritje të rezultatit ose të tarifimit, importimi i një rezultati ACTIVE ose FAILED mund të çojë në arkëtimin e tarifës së ruajtur për atë porosi. Kjo degë e sinkronizimit nuk tarifon sërish një regjistrim të tarifuar më parë.
Ndiqni rezultatin real
Një përgjigje e suksesshme HTTP mund të përmbajë një regjistrim verifikimi në pritje. Ruani vlerën e tij vettingId dhe shqyrtoni vettingStatus, arsyet, pikëzimin dhe datat e hyrjes në fuqi dhe të skadimit, nëse janë të disponueshme. PENDING dhe UNSCORE kërkojnë ndjekje të mëtejshme; ACTIVE, FAILED dhe EXPIRED përshkruajnë rezultate të ndryshme. Vetëm pranimi HTTP nuk dëshmon një pikëzim të favorshëm ose pranueshmëri për fushata.
Përdorni statusin e verifikimit të jashtëm për të ndjekur regjistrimin. Leximi ose importimi i një rezultati përfundimtar mund të çojë në arkëtimin e tarifës për një porosi të mëparshme me pagesë; ky veprim nuk përjashtohet domosdoshmërisht nga një tarifë ekzistuese e pashlyer.
Riprovoni të njëjtën kërkesë të synuar
Përdorni një Idempotency-Key për çdo veprim të synuar dhe ruani saktësisht metodën, shtegun, parametrat e kërkimit dhe bajtet e trupit të kërkesës. Çelësat mbështesin 1–128 karaktere ASCII të printueshme pa hapësira. Një kërkesë e dyfishuar, përpunimi i së cilës është ende në vijim, mund të kthejë 409 me Retry-After. Kërkesat e përfunduara kthejnë sërish përgjigjen e tyre të ruajtur, përfshirë gabimet. Respektoni kufijtë e shpeshtësisë së kërkesave.
Një përgjigje 502 e ruajtur në memorien e përkohshme mund të vijë pas një dështimi të transportit. Një përgjigje 500 e ruajtur në memorien e përkohshme me requestId mund të nënkuptojë se regjistri e pranoi veprimin, por ruajtja lokale ose faturimi dështoi. Ruani identifikuesin e kërkesës, shqyrtoni regjistrimet aktuale dhe sqaroni gjendjen me ekipin e mbështetjes përpara se të përdorni një çelës të ri. Mos supozoni se gabimi do të thotë që nuk ekziston asnjë porosi.