Агуулгыг алгасах

Go-live checklist

Live төлбөр авахаас өмнө багаараа нэг удаа давж, тэмдэглэх хэвлэх жагсаалт. Хугацаа: 1–2 цаг (бүх урсгалаа test горимд нэг удаа давсны дараа). Хэрэгтэй: test горимд ажиллаж буй интеграци (Sandbox), консолын хандалт.

Техник

Webhook

  • Live орчны webhook endpoint https://, нийтийн хаяг, redirect-гүй, өөрийн secret-тэй (test-ийнхээс тусдаа); endpoint-ийн «Тест илгээх» (…/webhook-endpoints/{eid}/test) ok: true. Event-ийн шүүлтүүр (event_types) таны handler-ийн хүлээдэг бүх төрлийг багтаасан.
  • Гарын үсгийг түүхий body-оор, бүх v1, ±300 секундээр шалгадаг (Гарын үсэг шалгах).
  • Gerege-Event-Id-аар давхардлыг арилгадаг; нэг event хоёр ирэхэд бараа хоёр удаа олгогдохгүй.
  • 2xx-ийг 10 секундэд буцаадаг (удаан ажил queue-д).
  • Дараалал баталгаагүй: хуучин event сүүлд ирэхэд төлөвийг ухраахгүй — GET-ээр дахин уншиж шийддэг (Idempotent handler).
  • Мэдэхгүй type-д 2xx хариулж үл тоомсорлодог.
  • Webhook ирээгүй ч ажиллана: тогтмол reconcile — Events API (GET /events, 30 хоног) эсвэл GET /payment-intents?status=… / ?reference=… — хүлээгдэж буй захиалга бүрийг шалгадаг (Тулгалт). Endpoint 5 хоног амжилтгүй бол auto_disabled болдог — админуудын мэдэгдлийг хэн хүлээж авахыг тохирсон.

Төлбөр

  • Дүн, тайлбар таны серверээс; description ≤ 80, захиалгын товч (Аюулгүй байдлын checklist).
  • Нэг захиалга = нэг intent = нэг Idempotency-Key; сүлжээний алдаа, 429, 5xx-д ижил key-ээр давтдаг.
  • Redirect-ийн дараа return_url?pi=-д итгэлгүй, серверээс GET /payment-intents/{id}-оор status, amount, reference-ийг тулгадаг.
  • Бүх төлөвийг боловсруулдаг: requires_confirmation, processing (202 хариу — хүлээгээд дахин унш), requires_capture, succeeded, partially_refunded, refunded, canceled, expired, failed (дахин төлөгдөж болно — захиалгыг бүү хаа) (Payment intent).
  • Алдааны кодуудад зөв зан төлөвтэй: in_progress (хүлээгээд дахин унш), idempotency_conflict, terminal_busy (нээлттэй intent-ийг цуцлаад дахин), expired, not_capturable, payouts_not_configured, payments_unavailable (Алдааны код).
  • Manual capture: гарсан бол capture, гараагүй бол cancel, capture_within дотор; хэсэгчлэн гарсан бол бүтэн capture + буцаалт.
  • Буцаалт: өөрийн Idempotency-Key, 202 / pending-ийг refund.succeeded / refund.failed-ээр дуусгадаг; 90 хоногийн хязгаар (Буцаалт).

Түлхүүр

  • Live secret зөвхөн сервер дээр, secret manager / орчны хувьсагчид; test-ээс live руу шилжихэд зөвхөн түлхүүр солигдоно — код, URL адил.
  • Сервер бүрт хамгийн бага scope-той, нэртэй түлхүүр; хэрэггүй test түлхүүрүүдийг хүчингүй болгосон.
  • Secret солих журам багт тодорхой: API түлхүүр давхцалтай (roll), анхдагч түлхүүр (POST …/credentials — одоо live secret-ийн цорын ганц зам) шууд, давхцалгүй (Аюулгүй байдлын checklist).

Бизнес ба бүртгэл

  • Байгууллага ба апп (kind: merchant эсвэл mini app) консолд бүртгэлтэй.
  • Submit-ийн шаардлага биелсэн: нууцлалын бодлого (privacy_url), үйлчилгээний нөхцөл (terms_url), тусламж (support_url) холбоос — https:// бол redirect-гүй 200 хариулдаг; апп-ын webhook URL (endpoint №1, POST …/webhook) тохируулсан; live secret анхдагч түлхүүрээр үүсгэсэн. Mini app бол шалгагдсан manifest (512×512 PNG icon) (Review-ийн шаардлага).
  • Худалдагч бол буцах host-ууд (return_hosts, ≤ 5, яг host) review-ээс өмнө бүртгэгдсэн (батлагдсаны дараа өөрчлөх нь дахин review).
  • Апп батлагдсан (батлагдахаас өмнө live түлхүүр 401 invalid_client).
  • Орлого хүлээн авах payout данс тохируулагдсан — админ байгууллагын өөрийн данс руу консолоос, эсвэл оператор (үгүй бол live intent 409 payouts_not_configured) (Payout данс).
  • Дэд худалдагч бүрийн payout холболтыг эзэмшигч нь Gerege App-д баталсан.
  • Шимтгэл, тооцооны хуваарийг оператортой тохирсон (Шимтгэл).
  • Худалдагчийн гэрээнд байгууллагын төлөөлөгч eID-ээр гарын үсэг зурсан (консол → Гэрээ; miniapp.agreements.sign эрх, eID-д бүртгэлтэй төлөөлөгч). Одоогоор submit, live түлхүүр гэрээг шаарддаггүй ч оператор шалгана.
  • Бизнесийн профайл (KYB) бөглөж, баталгаажуулж илгээсэн (консол → Бизнесийн профайл, 1.14.0): худалдааны нэр, лого (512×512 PNG), MCC, вэбсайт, тусламж/техник/санхүүгийн имэйл ба тусламжийн утас (кодоор баталгаажуулна), 25 %-иас дээш эзэмшигчид, улсын бүртгэлийн гэрчилгээ (MCC шаардвал тусгай зөвшөөрөл). Хуулийн нэр ба регистр нь байгууллагыг eID-ээр нээх үед бүртгэгдсэнээс ирнэ. Илгээх нь зөвхөн админ, дахин нэвтэрсний дараа; батлах нь оператор.
  • Go-live checklist-ийг серверээс шалгасан: GET /api/v1/miniapp/dev/account (байгууллага) ба GET /api/v1/miniapp/dev/apps/{id}/go-live (апп) — алхам бүр done.
  • Хязгаараа мэдэж байна: шинэ худалдагч (new) нэг төлбөр ≤ 1 000 000₮, өдөрт ≤ 10 000 000₮; standard 10 сая / 200 сая; ихийг консолоос хүснэ. Суулгац go-live-ийн дүрмийг асаасан бол (MINIAPP_GO_LIVE=on) гэрээ, батлагдсан профайл, хязгааргүйгээр live intent 409 (agreement_required, business_profile_required, business_limit_exceeded …).

Хэрэглэгчийн туршлага

  • «Gerege App-аар төлөх» товч тодорхой; дарахад ачаалах төлөв.
  • QR / терминал: payment_intent.claimed ирэхэд «Утсаараа баталгаажуулна уу» гэж харуулдаг; хүлээх хугацааг (expires_at) харуулдаг.
  • Цуцлах товч (cancel), хугацаа дуусах (expired), татгалзсан (failed) үед ойлгомжтой Монгол мессеж + дахин оролдох.
  • Амжилттай бол баримт/захиалгын дугаар (reference) харуулдаг; буцаалтын бодлого төлбөрөөс өмнө ил.
  • Компьютер ба утасны аль алинд нь redirect checkout-ын бүх замыг давсан.

Live болсны дараах эхний өдөр

  • Бодит бага дүнтэй (жишээ нь 100₮) нэг төлбөр → webhook → олголт → буцаалт.
  • Консолын «Хүргэлтүүд»-д (live endpoint) failed event алга; самбарын төлбөрийн жагсаалт таны захиалгуудтай таарч байна.
  • Тусламжийн холбоо барих мэдээлэл (Тусламж) багт тодорхой.