Natatanging pagkakakilanlan ng pagbabayad - ano ito? Para saan ito? Ito ang pinaka FAQ Ang mga tanong na itinatanong ng mga negosyante kapag nagbabayad ng buwis sa bangko, kapag hiniling ng isang empleyado ng bangko na ipahiwatig ito, ay nakakagulat. Saan ko ito mahahanap, paano ko ito makukuha, at magagawa ko nang wala ito? Kaya, ang isang tool na nilikha upang pasimplehin ang pamamaraan ay nagresulta sa mga bagong isyu na kailangang linawin.
Ano ang isang natatanging identifier?
Ang isang natatanging identifier ng pagbabayad ay isang 20-digit na code na dapat tukuyin kapag nagbabayad ng mga utang sa buwis. Ginagawa nitong posible na madali at mabilis na magbayad ng mga buwis mula sa iyong personal na account sa website ng serbisyo sa buwis. Ang pamamaraang ito ay lubos na nagpapadali at nagpapabilis sa pamamaraan ng operasyon. Ang pagbabayad ay nangyayari nang mabilis, at samakatuwid sa oras, na nag-iwas sa mga pagkaantala, na nangangahulugan ng mga parusa at interes.
Ang paggamit ng natatanging identifier ay nagbibigay-daan sa mga negosyante, legal na entity at indibidwal na magbayad ng mga buwis sa isang maginhawang paraan. Ngunit ang pagtanggap at pagpuno ng mga form ng dokumentasyon ng buwis sa kasong ito ay may sariling mga katangian na dapat isaalang-alang. Ang problema ay nakasalalay din sa katotohanan na ang serbisyo ng impormasyon ng gobyerno mismo ay may isang kumplikado, nakakalito na istraktura na kahit na ang isang may karanasan na gumagamit ay hindi laging maunawaan.
Para saan ito?
Ito ay kinakailangan upang malaman ng Federal Tax Service kung kailan at kung saan tao natanggap ang pera sa account. Mayroong milyon-milyong mga gumagamit na nakarehistro sa GIS; mahirap matukoy kung kanino at para sa kung anong mga layunin ang inililipat ng pera. Iyon ang dahilan kung bakit, sa pamamagitan ng utos ng Ministri ng Pananalapi No. 107n na may petsang Nobyembre 12, 2013, ang mga patakaran ay binago, ayon sa kung saan ang isang natatanging identifier para sa accrual na mga pagbabayad ay lumitaw nang hiwalay para sa mga buwis.
Kailangan ito ng serbisyo sa buwis upang mas epektibong maipatupad ang patakaran sa pananalapi at matukoy ang mga patuloy na defaulter. Kailangan ng mga legal na entity at indibidwal ang pinaka-maginhawa at mabilis na paraan magbayad ng buwis. Bilang resulta, makokontrol ng gobyerno ang mga aksyon ng mga opisyal ng buwis at itigil ang mga kaso kapag ang kanilang mga aksyon ay lumampas sa mga kapangyarihan na ipinagkatiwala sa kanila, na madalas na nangyari sa nakaraan. Ang mga negosyante ay hindi gaanong umaasa sa kagustuhan ng indibidwal at dumaranas ng mga ilegal na pangingikil. Ang bilang ng mga inspeksyon na isinagawa ay nabawasan.
Sino ang dapat magpahiwatig nito?
Ang parehong mga ordinaryong mamamayan, negosyante (mga indibidwal), at legal na entity ay maaaring magpahiwatig ng natatanging pagkakakilanlan ng pagbabayad. Magagawa ito kapag direktang nagbabayad ng buwis sa information system account o sa pamamagitan ng bangko. Kapag naglilipat, dapat mong isaalang-alang na ang pagbabayad sa pamamagitan ng Sberbank ay may sariling mga katangian. Mayroon silang sariling espesyal na form, kapag pinupunan ito, hindi kailangang tukuyin ang isang natatanging identifier. Ang UIN ay ipinahiwatig kapag nagbabayad ng mga buwis at mga tungkulin ng estado sa pamamagitan ng serbisyo ng Serbisyo ng Estado o sangay ng bangko.
Kung ang isang indibidwal o legal na entity ay nagpuno ng mga dokumento sa pagbabayad para sa pagbabayad ng mga buwis at mga bayarin, ang deadline ng pagbabayad kung saan ay hindi pa nag-e-expire, kung gayon hindi siya maaaring magpasok ng isang natatanging identifier, ngunit magpasok ng isang zero sa takdang petsa para sa pagpasok ng mga detalye. Bagama't ang pamamaraang ito ng pagpuno sa linya ay pinahihintulutan ng batas, kapag nagbabayad sa pamamagitan ng bangko, ang empleyado ay maaaring mangailangan ng pagpuno sa linya ng isang 20-digit na numero ng pagbabayad at may karapatang tumanggi na tanggapin ang pagbabayad. Samakatuwid, mahalagang malaman kung aling mga kaso ito ay dapat ipahiwatig, at kung saan ito ay hindi kinakailangan.
Sa anong mga kaso kinakailangan na ipahiwatig ito?
Dapat pansinin na ang identifier ay hindi palaging kailangang tukuyin, ngunit sa ilang mga kaso lamang, na inilarawan sa mga patakaran at regulasyon ng Bank of Russia (sa partikular, regulasyon No. 383-P). UIN - isang natatanging identifier ay ipinahiwatig sa dalawang kaso:
- Kung ito ay ipinahiwatig ng tatanggap ng mga pondo at ibinigay sa isang indibidwal o legal na entity na obligadong bayaran ang mga ito alinsunod sa mga tuntunin ng kasunduan. Sa kasong ito, awtomatikong itinalaga ang identifier.
- Kapag naglilipat ng mga pondo sa mga awtoridad sa buwis. Pinunan ng isang negosyante o indibidwal ang mga espesyal na field (linya) ng slip ng pagbabayad sa papel o electronic form. Sa kasong ito, ang pagpuno ay nagdudulot ng ilang mga paghihirap. Pagkatapos ng lahat, hindi palaging alam ng isang negosyante ang kanyang natatanging numero ng pagkakakilanlan ng pagbabayad o kung saan ito kukuha.
Sa pangalawang kaso, karamihan sa mga nagbabayad ng buwis ay nakakaranas ng mga paghihirap dahil hindi nila alam kung saan ito kukunin at kung saan ito ipahiwatig sa dokumento. Ang maling tinukoy na data ay humahantong sa mga pagkaantala sa pagbabayad, mga parusa at multa.
Saan at paano ako makakakuha ng ID?
Paano ko malalaman ang impormasyon tungkol sa natatanging pagkakakilanlan ng pagbabayad, pati na rin kung tinanggap ang pagbabayad? Maaari mong suriin ito tulad ng sa personal na account GIS pagkatapos ng pagpaparehistro sa system, at sa pagtanggap ng isang order sa pagbabayad sa kaso ng mga huli na pagbabayad. Ngunit ito ay isang matinding kaso. Malalaman ng negosyante ang numero mula sa mga dokumento na nagpapahiwatig ng pagkakaroon ng utang o multa sa mga awtoridad sa buwis.
Kung walang mga overdue na pagbabayad, ngunit kailangan mong ipahiwatig ang UIN, kailangan mo lang magpadala ng kahilingan sa serbisyo ng buwis upang makakuha ng numero.
Paano ito punan ng tama?
Kapag nagbayad ang mga nagbabayad ng buwis sa sistema ng badyet ng Russian Federation, pinupunan nila ang isang order sa pagbabayad. Bilang karagdagan sa natatanging identifier, dapat ipahiwatig ng negosyante ang:
- BIC ng institusyon kung saan gagawin ang pagbabayad;
- pangalan ng bangko, ang legal na address nito;
- ang kasalukuyang account kung saan gagawin ang paglilipat;
- uri ng pagbabayad (code);
- petsa ng operasyon.
Ang numero ay ipinasok sa linya ng natatanging pagkakakilanlan ng pagbabayad - 22 (field code). Huwag punan kung ang pagbabayad ay magaganap sa oras. Sa kasong ito, ilagay ang "0" (zero) sa linyang ito.
Ano ang gagawin kung ang dokumento ay naglalaman na ng UIN?
Minsan, lalo na kapag gumagawa ng mga pagbabayad sa pamamagitan ng mga dalubhasang sistema ng impormasyon, kapag pinupunan ang isang order nang elektroniko sa linya (ang code nito ay 22), isang natatanging identifier ng pagbabayad ang lilitaw sa sarili nitong. Ano ang dapat nating maramdaman tungkol dito? Ito ba ay itinuturing na isang error kung cash binayaran ba sila sa oras? Sa katunayan, walang pagkakamali. Maaari kang magbayad alinman sa pamamagitan ng pagpahiwatig ng numero ng ID o sa pamamagitan ng paglalagay ng "0" sa linya. Hinihiling lang nila sa iyo na ipahiwatig ang pagkakakilanlan kapag huli na ang pagbabayad, iyon ay, sa kahilingan ng tanggapan ng buwis.
Kahit na posible na magbayad nang walang mga paghihigpit, ang diskarte na ito ay hindi kanais-nais. Ang isang negosyo ay dapat na makilala sa pagitan ng mga regular na pagbabayad ng buwis at ang mga binabayaran sa kahilingan ng mga awtoridad sa buwis. Makakatulong ito na maiwasan ang kalituhan sa pag-uulat.
Ngunit kahit na hindi posible na malaman at ipahiwatig ang pagkakakilanlan sa pagkakasunud-sunod, hindi nito binibigyan ang mga bangko ng karapatang tumanggi na tanggapin ito. Obligado ang bangko na tumanggap at maglipat ng mga pondo, kahit na hindi tinukoy ang UIP (natatanging pagkakakilanlan ng pagbabayad). Ang panuntunang ito ay nabaybay sa mga opisyal na dokumento ng serbisyo sa buwis. Malinaw nitong isinasaad na kailangan lang ipahiwatig ng isang indibidwal o legal na entity ang kanilang TIN at ilagay ang "0" sa linya (code 22) ng natatanging pagkakakilanlan ng pagbabayad. Sa kasong ito, ang bangko ay walang karapatang tumanggi na ilipat ang pagbabayad. Ngunit dapat isaalang-alang ng negosyante na sa kaganapan ng isang pagkakamali o pagkaantala, ang bangko ay hindi mananagot.
Ano ang ibig sabihin ng code: decoding ang identifier
Ang identifier ay na-decrypt gaya ng sumusunod:
- Ang mga numero 1 hanggang 3 ay nagpapahiwatig ng code ng departamento ng buwis kung saan matatanggap ang mga pondo.
- Ang numero 4 ay nagpapahiwatig ng uri ng pagbabayad. Laging zero ang lugar na ito.
- Mga numero mula 5 hanggang 19. Ipahiwatig ang code ng dokumento sa sistema ng buwis. Ang bawat nagbabayad ay itinalaga ng sarili nitong espesyal na code, batay sa nakaraang bersyon ng index ng dokumento.
- Digit 20. Tinutukoy ng numero nito kung aling ahensya ng gobyerno ang nagbe-verify ng pagbabayad. Kinakalkula na isinasaalang-alang ang natitirang 19 na numero ng code.
Ang natatanging pagkakakilanlan ng pagbabayad ay kapareho lamang ng index ng dokumento kung ang index ay binubuo ng 20 digit.
Ano ang mangyayari kung hindi mo ito tinukoy?
Gamit ang numero ng UIN, awtomatikong naitatala ang mga buwis at iba pang mga pagbabayad sa badyet. Ang impormasyon tungkol sa mga pagbabayad sa badyet ay inililipat sa iisang database. Kung maling code ang ipinasok mo o hindi ito tinukoy, hindi makikilala ng system ang pagbabayad at hindi ililipat ang pera. Ito ay puno ng mga problema tulad ng:
- ang kumpanya ay magkakaroon ng utang sa badyet at mga pondo;
- ang mga parusa ay patuloy na maiipon;
- kakailanganin mong linawin ang pagbabayad at alamin ang kapalaran nito;
- ang pera ay darating sa badyet o mga pondo na may pagkaantala.
Kung ang isang negosyante ay walang o hindi alam ang isang natatanging pagkakakilanlan ng pagbabayad kung saan ito kukunin, maaari niyang gamitin ang serbisyo ng suporta sa GIS anumang oras, sa halip na maghintay para sa mga awtoridad sa buwis na kumilos. Kung ang isang negosyante ay walang access sa Internet at sa electronic system ng State Services, maaari siyang magpadala ng regular na sulat sa pinakamalapit na tanggapan ng buwis o magpakita nang personal upang makatanggap ng isang identifier.
Anong mga dokumento ang kailangan para makakuha ng ID?
Ang lahat ay nakasalalay sa form kung saan iguguhit ang dokumento at kung paano magbayad. Kung ito ay isang papel na dokumento, dapat kang magpadala ng nakasulat na kahilingan sa awtoridad sa buwis. Sa liham, ipahiwatig ang mga detalye ng iyong pasaporte, numero ng INN at SNILS. Ang isang natatanging pagkakakilanlan ng pagbabayad ay ipapadala sa isang sulat ng tugon. Kung ang isang legal na entity o indibidwal ay pumunta sa departamento nang personal upang matanggap ang impormasyong ito, dapat na kasama niya ang mga dokumentong ito. Kinakailangan nilang punan ang mga form.
Upang makatanggap ng mga detalye sa elektronikong paraan, kailangan mo munang magparehistro sa isang solong sistema ng impormasyon sa website ng Mga Serbisyo ng Estado, na nagsasaad ng parehong data tulad ng sa nakasulat na kahilingan. Pagkatapos nito, magpapadala ng liham sa iyong tirahan na may access key. At pagkatapos lamang nito maaari kang humiling upang makakuha ng natatanging identifier. Karaniwan ang serbisyong ito ay ibinibigay sa loob ng ilang oras pagkatapos ng aplikasyon. Walang kinakailangang mga dokumento.
Tulad ng nakikita mo, walang kumplikado kapag ginagamit ang identifier. Hindi magiging mahirap na makilala siya. Upang gawin ito, hindi mo kailangang mangolekta ng isang bungkos ng mga dokumento o sertipiko. Ngunit ang mga buwis ay maaaring bayaran sa isang madaling paraan at anumang oras. Kung ang mga dating legal na entidad at indibidwal ay kailangang gumugol ng oras at pera upang magbayad ng buwis, kung gayon sa tulong nito maaari silang mabayaran nang hindi umaalis sa bahay o opisina, nang hindi nakakaabala sa trabaho.
- Dapat tanggapin ng interface ang mga kahilingan sa HTTPS mula sa mga subnet IP address:
- 79.142.16.0, mask 255.255.240.0 (20)
- 91.232.230.0, mask 255.255.254.0 (23)
- Dapat iproseso ng interface ang mga parameter na ipinasa ng system gamit ang pamamaraang HTTP GET.
- Ang interface ay dapat bumuo ng tugon sa system sa XML format sa UTF-8 encoding.
- Ang pagpapalitan ng impormasyon ay isinasagawa sa mode na "request-response", at ang bilis ng pagtugon ay hindi dapat lumagpas sa 60 segundo, kung hindi, sinira ng system ang koneksyon dahil sa isang timeout.
- Kung ang inaasahang bilang ng mga pagbabayad para sa mga serbisyo ng konektadong provider ay inaasahang magiging intensive (hanggang sa 10 pagbabayad kada minuto o higit pa), kinakailangan na ang interface ay sumusuporta sa multi-threaded na komunikasyon hanggang sa 10-15 sabay-sabay na koneksyon.
- Dapat tanggapin ng interface ang mga kahilingan sa pamamagitan ng HTTPS protocol sa isa sa mga sumusunod na TCP port: 80, 81, 443, 8008, 8080, 8081, 8090, 8443, 4433. Hindi pinapayagan ang paggamit ng iba pang mga port.
Mga pangunahing prinsipyo ng interface
Ang lahat ng mga kahilingan ay ipinadala gamit ang GET na paraan, ang mga parameter ay ipinapasa sa landas ng kahilingan.
Ang paglilipat ng impormasyon sa pagbabayad sa provider ay isinasagawa ng QIWI Wallet system sa dalawang yugto - pagsuri sa katayuan ng subscriber at direktang pagbabayad. Ang isang paunang yugto ng pagkuha ng mga karagdagang parameter ng pagbabayad mula sa isang provider na nagbibigay sa subscriber ng ilang mga serbisyo ay maaari ding idagdag upang ipaalam sa nagbabayad at magdagdag ng mga parameter ng pagbabayad na pinili ng nagbabayad.
Ang uri ng kahilingan ay ipinapadala ng QIWI Wallet system sa command variable - isang string na kumukuha ng mga value check, pay o getInfo:
Mga parameter ng query
Ang lahat ng mga parameter ay kinakailangan sa mga query kung saan ginagamit ang mga ito.
| Parameter | Format | Paglalarawan | Sa anong mga query ito ginagamit? |
|---|---|---|---|
| txn_id | Integer hanggang 20 character ang haba | Natatanging pagkakakilanlan ng pagbabayad sa QIWI system. Ginagamit ang identifier na ito upang malutas ang mga kontrobersyal na isyu. | suriin, bayaran |
| sum | Ang isang fractional number na tumpak hanggang sa hundredths ay ginagamit bilang isang separator. (tuldok). Kung ang kabuuan ay kumakatawan sa isang integer, pagkatapos ay pupunan pa rin ito ng isang tuldok at mga zero, halimbawa - 152.00. | Halaga ng bayad | suriin, bayaran |
| ccy | Alpha-3 ISO 4217 currency code | Pera sa pagbabayad | suriin, bayaran |
| txn_date | YYYYMMDDHHMMSS | Petsa ng pagbabayad (ang petsa ng pagbabayad sa system ay nangangahulugang ang petsa na natanggap ang kahilingan mula sa kliyente). Batay sa petsang ito, ang karagdagang pagkakasundo ng mutual settlements sa pagitan ng QIWI Wallet at ng provider ay isinasagawa. Halimbawa, nagpadala ang kliyente ng kahilingan sa QIWI Wallet system noong 12/31/2010 sa 23:59:59, at ipinadala ng QIWI Wallet system ang kahilingan nito sa provider noong 01/01/2011 sa 00:00:05. Maaari itong humantong sa isang isyu sa pagkakasundo sa pagbabayad kung ilalagay ng system ng provider ang transaksyon sa susunod na panahon ng pagsingil. Upang maiwasan ang mga ganitong problema, binibigyan ng QIWI Wallet ang provider ng orihinal na petsa ng pagbabayad. |
magbayad |
| account | Isang string na naglalaman ng mga titik, numero at espesyal na character, hanggang 200 character ang haba | Subscriber ID. Tinutukoy ng provider ang subscriber nito sa pamamagitan ng isang natatanging identifier (personal na account number, numero ng telepono, login, atbp.). Bago ipadala sa provider, pinapatunayan ang identifier ayon sa isang regular na expression na . | suriin, magbayad, kumuha ngInfo |
| dagdag | Ang mga katanggap-tanggap na numero ay mga numero (0-9), underscore (_) at maliliit na letrang Latin (a-z) | Mga karagdagang detalye ng pagbabayad (mga karagdagang field). Maaaring gamitin ang mga parameter na ito kung hindi magagawa ang pagbabayad nang walang karagdagang data (hindi sapat ang isang user ID sa system ng provider). Halimbawa, ang user ID ay isang numero ng credit card, ngunit para makapagbayad kailangan mo ring tukuyin ang petsa ng pag-expire ng card. Ang listahan ng mga kinakailangang field na ililipat sa provider ay dapat na nakasaad sa . |
suriin, bayaran |
| prvId | Integer | Tagatukoy ng serbisyo sa karaniwang sistema ng provider. | getInfo |
| parameter_name | Ang format ng pangalan at halaga ng mga parameter ay tinukoy ng provider sa . | Mga karagdagang parameter para sa pagkakakilanlan ng subscriber | getInfo |
Upang suportahan ang pagpapalawak at mapanatili ang functionality ng serbisyo ng provider sa panahon kung kailan pinagana ang iba't ibang function na ibinigay ng protocol (halimbawa, pagpapagana ng paglipat ng mga bagong detalye ng pagbabayad), ipinapalagay na hindi pinipigilan ng provider ang paglitaw ng bago. Mga parameter ng HTTP sa kahilingan.
Ito ay ginagarantiyahan na ang paglitaw ng mga bagong parameter sa isang kahilingan ay hindi hahantong sa pangangailangan na baguhin ang pagpoproseso ng kahilingan sa bahagi ng provider, maliban kung ang naturang pagbabago sa lohika ay napagkasunduan sa provider.
Format ng Tugon
Dapat ibalik ng provider ang tugon sa mga kahilingan sa system sa XML na format. Ang pangkalahatang istraktura ng sagot ay ipinapakita sa tab sa kanan.
Kung nabigo ang alinman sa mga kahilingan sa provider, magbabalik ang provider ng error code alinsunod sa .
Ang sistema ng impormasyon ng provider ay hindi dapat maglaman ng dalawang matagumpay na nakumpletong pagbabayad na may parehong txn_id number. Kung muling magpadala ang system ng kahilingan na may txn_id identifier na mayroon na sa sistema ng impormasyon ng provider, dapat ibalik ng provider ang resulta ng pagproseso ng nakaraang kahilingan.
Maaaring naglalaman ang tugon ng mga sumusunod na tag:
Halimbawa, mayroong isang sitwasyon: nagpadala ang kliyente ng kahilingan sa system noong 12/31/2010 sa 23:59:59. Isinasaalang-alang ang pagkaantala sa pagproseso ng data at pagpapadala ng impormasyon sa pamamagitan ng mga channel ng komunikasyon, ang bayad ay matatanggap ng provider sa 01/01/2011 00:00:05 at, nang naaayon, ay isasaalang-alang sa system ng provider sa isa pang pag-uulat panahon. Upang maiwasan ang mga problema sa iba't ibang panahon ng pag-uulat kapag nagsasagawa ng mga pagkakasundo, kinakailangan na ibalik ng provider ang petsa kung kailan isinasagawa ang accounting sa system nito.
Halimbawa ng kahilingang suriin ang katayuan ng account ng subscriber at magparehistro ng pagbabayad
Halimbawang kundisyon:
Ang application ng pagbabayad ng provider na payment_app ay matatagpuan sa yourservice.prv.ru, sinusuportahan ng server ang mga koneksyon sa HTTPS sa port 8443.
Upang suriin ang katayuan ng subscriber, ang QIWI Wallet system ay bumubuo ng isang kahilingan (tingnan ang tab sa kanan).
GET /payment_app?command=check&txn_id=1234567& account=4957835959&sum=10.45&ccy=RUBAng kahilingan ay naglalaman ng mga parameter:
- command=check – identifier ng kahilingan upang suriin ang katayuan ng subscriber;
Matagumpay na tugon mula sa provider (tingnan ang tab sa kanan).
Ang ibinabalik na resulta=0 sa isang kahilingan sa pagsusuri ay nagpapahiwatig na ang personal na account ng subscriber na may kaukulang numero sa field ng account ay maaaring mapunan ng halagang tinukoy sa kahilingan sa field ng kabuuan. Matapos matagumpay na suriin ang katayuan ng account ng subscriber, ang system ay nagpapatuloy sa pagbuo at pagpapadala ng isang kahilingan upang i-top up ang balanse (kahilingan sa pagbabayad).
Halimbawa ng kahilingang mag-top up ng personal na account
Halimbawang kundisyon:
Upang kumpirmahin ang pagbabayad, ang QIWI Wallet system ay bumubuo ng isang kahilingan (tingnan ang tab sa kanan).
GET /payment_app?command=pay&txn_id=1234567& txn_date=20110815120133&account=4957835959&sum=10.45&ccy=RUB HTTP / 1.1 Host : yourservice.prv.ru:8443 Tugon ng providerAng kahilingan ay naglalaman ng mga parameter:
- command=pay – identifier ng kahilingan na i-top up ang balanse ng subscriber;
- txn_id=1234567 – panloob na numero ng pagbabayad sa QIWI system;
- txn_date=20090815120133 – petsa ng pagpaparehistro ng pagbabayad sa QIWI system;
- account=4957835959 – tagatukoy ng subscriber sa sistema ng impormasyon ng provider;
- sum=10.45 – halagang ikredito sa personal na account ng subscriber;
- ccy=RUB – currency ng halagang na-kredito sa personal na account ng subscriber.
Sa pamamagitan ng pagbabalik ng resulta=0 sa kahilingan sa pagbabayad, iniuulat ng provider ang matagumpay na pagkumpleto ng pagpapatakbo ng muling pagdadagdag ng balanse. Kinukumpleto ng system ang pagproseso sa transaksyong ito.
Ang opsyonal na field ng komento ay naglalaman ng komento ng serbisyo.
Halimbawa ng isang kahilingan para sa karagdagang data ng pagbabayad
Halimbawang kundisyon:
Ang application ng pagbabayad ng provider na payment_app ay matatagpuan sa yourservice.prv.ru, sinusuportahan ng server ang mga koneksyon sa HTTPS sa port 8443.
Upang makakuha ng karagdagang data ng pagbabayad, ang QIWI Wallet system ay bumubuo ng isang kahilingan (tingnan ang tab sa kanan).
GET /payment_app?command=getInfo&prvId=12345& account=4957835959&name1=%26%30AB&name2=0 HTTP / 1.1 Host : yourservice.prv.ru:8443 Tugon ng providerAng kahilingan ay naglalaman ng mga parameter:
- command=getInfo – kahilingan ng identifier na makakuha ng karagdagang data ng pagbabayad para sa subscriber;
- prvId=12345 – identifier para sa pagtukoy sa serbisyo ng provider;
- account=4957835959 – tagatukoy ng subscriber sa sistema ng impormasyon ng provider;
- name1, name2 – karagdagang mga identifier ng subscriber.
Tingnan ang tab sa kanan para sa tugon ng provider.
Ang pagbabalik ng resulta=0 sa isang kahilingang getInfo ay nagpapahiwatig na ang kahilingan ay matagumpay na nakumpleto at ang karagdagang data na ipapakita sa subscriber ay natanggap.
Ang opsyonal na field ng komento ay naglalaman ng komento ng serbisyo.
Araw-araw na pagkakasundo
Bago ang 10:00 oras ng Moscow, ang sistema ay bumubuo at nagpapadala sa tinukoy na address ng isang elektronikong rehistro ng mga tinanggap na pagbabayad para sa nakaraang araw.
Ang rehistro ay may sumusunod na istraktura:
Petsa ng transaksyon (Moscow);Petsa ng ulat; Uri; Numero ng transaksyon; ID ng pera ng transaksyon; Halaga ng transaksyon; Komento ng merchant; Numero ng transaksyon/invoice ng merchant; Petsa ng paglabas ng invoice; QW ID; Account; Refund ID
Ang mga patlang ay pinaghihiwalay ng isang palatandaan; , ang fractional na bahagi ng halaga ay pinaghihiwalay ng isang tuldok, ang petsa/oras ay Moscow, ang line feed ay maaaring binubuo ng alinman sa mga character na x0D x0A o simpleng x0D.
Halimbawa:
31.02.2005 00:04:00;31.02.2005
00:00:00;Pagbabayad;3464968222;USD;5.00;;;;;0957835959;;
02/31/2005 00:04:00;02/31/2005 00:00:00;Pagbabayad;3464968912;RUB;10.34;;;;; [email protected];;
02/31/2005 00:11:00;02/31/2005 00:00:00;Pagbabayad;3464974548;EUR;4.72;;;;;;ABC-12345;;
Kasama sa system ang mga matagumpay na nakumpletong pagbabayad lamang sa rehistro.
Ang mga pagbabayad na natanggap kapwa sa pamamagitan ng online na pagmemensahe at sa rehistro ay itinuturing na nakumpirma.
Kung ang rehistro ay hindi naglalaman ng mga pagbabayad na ginawa sa database ng provider, o naglalaman ng mga pagbabayad na wala sa database ng provider, o kung ang rehistro ay hindi pa natanggap, dapat kang makipag-ugnayan sa QIWI contact person na tinukoy sa kasunduan bago ang 12:00 upang linawin ang sitwasyon at gumawa ng desisyon.
Karagdagang mga opsyon sa pagpapahintulot sa kahilingan
Sa application ng koneksyon, maaaring tukuyin ng provider ang isang identifier (login) at isang lihim na password para dito, na ginagamit para sa awtorisasyon kapag gumagawa ng mga kahilingan mula sa QIWI.
Ang data ng pahintulot na ito ay ipinapadala ayon sa karaniwang mga pangunahing panuntunan sa pagpapatotoo para sa mga kahilingan sa HTTP(S). Isang Authorization HTTP header ay idinagdag sa kahilingan. Ang header ay naglalaman ng string Basic (na may puwang sa dulo) at ang "login:password" na pares na naka-encode sa BASE64:
Awtorisasyon: Basic ***
BASE64("Login:Password") = "***"
Aplikasyon para sa koneksyon (sample)
Listahan ng mga exit code
Kapag nagpoproseso ng mga kahilingan mula sa system, dapat itugma ng provider ang lahat ng error na nagaganap sa application nito sa listahan sa ibaba at ibalik ang mga kaukulang code sa elemento.
Ang + sign sa column na "fatality" ay nagpapahiwatig na ang error ay nakamamatay. Para sa QIWI Wallet system, ang isang nakamamatay na error ay nangangahulugan na ang muling pagpapadala ng isang kahilingan na may parehong mga parameter ay hahantong sa isang 100% na pag-uulit ng parehong error - samakatuwid, ang system ay huminto sa pagproseso ng kahilingan ng kliyente at kinukumpleto ito ng isang error.
Ang isang hindi nakamamatay na error ay nangangahulugan sa system na ang pag-uulit ng kahilingan na may parehong mga parameter pagkatapos ng isang tiyak na tagal ng panahon ay malamang na humantong sa tagumpay. Uulitin ng system ang mga kahilingang nabigo nang may hindi nakamamatay na error, patuloy na tataas ang pagitan, hanggang sa magtagumpay o mabigo ang operasyon, o hanggang sa mag-expire ang 24 na oras na buhay ng kahilingan.
Ang kakulangan ng koneksyon sa server ng provider ay isang hindi nakamamatay na error.
Ang kawalan ng elemento sa tugon (maling XML, page na pansamantalang hindi available ang Serbisyo, atbp.) ay isa ring hindi nakamamatay na error.
| Code |
|---|
Pangkalahatang Impormasyon
Paglalarawan ng mga parameter ng input
Paglalarawan ng mga parameter ng output
o
Output: XML na dokumento ayon sa scheme WS_ULIPOTVID_2_311_09_04_02_01.XSD
Ang mga kumplikadong uri ng mga parameter ay inilalarawan sa Appendix na "Paglalarawan ng Pangkalahatang Istruktura ng Data" (sa mga talata 10, 6, 9).
Ibalik ang mga code
| № | Ibalik ang code | Ibalik ang paglalarawan ng code | Mga kondisyon ng paglitaw | Komento |
| 1 | 01 | Ang hiniling na impormasyon ay hindi natagpuan | Nangyayari kung ang impormasyon tungkol sa legal na entity ay hindi matatagpuan sa Unified State Register of Legal Entities | |
| 2 | 51 | Tinanggap ang kahilingan para sa pagproseso | Nangyayari kapag matagumpay na tinanggap ang isang kahilingan para sa pagproseso | |
| 3 | 52 | Ang sagot ay hindi handa | Nangyayari kapag ang isang tugon sa isang kahilingan na matagumpay na tinanggap para sa pagproseso ay hindi pa handa | Ginagamit para sa asynchronous na kahilingan |
| 4 | 53 | Ang impormasyon tungkol sa isang legal na entity/indibidwal na negosyante ay hindi maaaring ibigay sa elektronikong paraan | Nangyayari kapag imposibleng makabuo ng tugon sa isang kahilingan sa electronic form. | |
| 5 | 82 | Error sa format-logical control | Nangyayari kapag ang dokumento (kahilingan) ay hindi tumugma sa xsd schema | Reserve, maaaring hindi gamitin |
| 6 | 83 | Walang kahilingan na may tinukoy na ID ng kahilingan at uri ng impormasyong hinihiling mula sa awtoridad na ito | Nangyayari sa isang sitwasyon kung saan ang kahilingan para sa isang resulta ng isang kahilingan para sa isang extract mula sa isang legal na entity ay nagpapahiwatig ng isang hindi tama (hindi alam) na pagkakakilanlan ng kahilingan at (o) isang kahilingan na may tulad na isang pagkakakilanlan ay hindi natanggap mula sa awtoridad na ito | Ginagamit para sa isang asynchronous na kahilingan (kapag natatanggap ang resulta ng isang kahilingan para sa isang extract mula sa isang legal na entity) |
| 9 | 99 | Error sa system | Nangyayari kapag may mga panloob na error sa IS software ng Federal Tax Service ng Russia |
Mga kaso ng pagsubok
Tugon sa isang kahilingan na matanggap ang resulta ng isang kahilingan para makakuha ng extract mula sa isang legal na entity, kung sakaling hindi pa naproseso ang kahilingan
Tugon sa isang kahilingan na matanggap ang resulta ng isang kahilingan para makakuha ng extract mula sa isang legal na entity na may return code 53
Tugon sa isang kahilingan para sa resulta ng isang kahilingan para sa isang extract mula sa isang legal na entity na may error (ang processing code kung saan ay hindi nakalaan)
(nagbabago ang mga halaga ng katangian at)
| |
Tandaan: Ang mga kundisyon para mangyari ang error na ito sa kapaligiran ng pagsubok ay artipisyal na na-trigger. Inilalarawan ng halimbawang ito ang pangkalahatang lohika at istruktura ng isang tugon ng error. Kapag sumusubok sa isang kapaligiran ng produksyon, ang pagbabalik ng eksaktong parehong tugon nang hindi nagbibigay ng mga kinakailangang kondisyon ay hindi posible.
Isinasagawa ang tseke upang matiyak na ang invoice at kasunod na pagbabayad ay maiproseso nang tama sa panig ng Proyekto.
Sa pinasimpleng pagsasama, ang user ID at order ay sinusuri ng dalawang beses: kapag pupunta sa form ng pagbabayad at kapag pumipili ng paraan ng pagbabayad.
Ang proyekto ay nangangailangan ng:
- User ID o URL ng pag-verify ng order(tukuyin sa Mga Teknikal na Setting sa iyong Personal na Account);
- Isang handler na may kakayahang tanggapin at kilalanin ang mga parameter ng kahilingan mula sa System at tumugon gaya ng inaasahan ng System.
Kung nabigo ang pag-verify ng ID pagkatapos mag-isyu ng invoice, hindi ibibigay ang invoice, at ire-redirect ang user sa page ng error sa pagbabayad na tinukoy ng proyekto gamit ang parameter return_url_fail o sa Mga Teknikal na Setting (kung ang pahina ay hindi tinukoy, ang isang katulad sa bahagi ng System ay ginagamit). Awtomatikong ipinapadala ang isang parameter sa page ng error sa pagbabayad gamit ang GET method err_msg may kahulugan "Walang ganyang karakter".
Humiling ng mga parameter mula sa System hanggang sa Proyekto
Ipinapadala ng system ang Proyekto ng kahilingan sa URL para sa pagsuri sa user ID o order na tinukoy sa Mga Teknikal na Setting sa Personal na Account.
- paraan ng paglipat - POST;
- encoding - UTF-8.
Parameter |
Paglalarawan ng parameter |
Format ng parameter |
Kinakailangang parameter |
|---|---|---|---|
| userid | User o order ID (katumbas ng value ng parameter palayaw V) | string(256) | Oo |
| userid_extra | Karagdagang impormasyong kinakailangan upang magbayad o mangolekta ng mga istatistika sa panig ng Proyekto (katumbas ng halaga ng parameter nick_extra ) | string(500) | Hindi |
| susi |
Lagda sa pagpapatunay ng kahilingan. Ito ay nabuo bilang isang hash gamit ang md5 algorithm mula sa pagsasama-sama ng mga sumusunod na parameter:
|
md5(0userid0project secret) | Oo |
| halaga | 0 | Oo | |
| binayaran | Sinusuri ang kahilingan sa tseke. Tumatanggap lang ng zero value (halaga = 0) | 0 | Oo |
| orderid | Payment ID sa Project accounting system (katumbas ng value ng parameter order_id V) | varchar(64) | Hindi |
Mga Opsyon sa Pagtugon sa Proyekto
Ang kahilingan ng System mula sa Proyekto ay dapat makatanggap ng tugon.
Ang mga sumusunod na panuntunan ay ginagamit upang ipasa ang mga parameter ng kahilingan:
- format - XML;
- encoding - UTF-8.
Parameter |
Paglalarawan ng parameter |
Format ng parameter |
Kinakailangang parameter |
|---|---|---|---|
| code |
Humiling ng response code.
|
(case sensitive) |
Oo |
| komento | Pag-decode ng response code sa kahilingan. Mga halimbawa ng teksto:
|
string(400) | Hindi |
Halimbawang tugon sa isang user ID o kahilingan sa pag-verify ng order
OO
Isang halimbawa ng kaunting System request handler kapag tumitingin ng user ID o order
//Pagbuo ng response function sendResponse($status, $message = "")( $response = ""."\n"; $response .=" ".$status.""."\n"; $response .="
Ano ang gagawin kung maulap ang iyong iPhone camera
Manu-manong pagtuturo sa sarili para sa pagtatrabaho sa isang computer: mabilis, madali, epektibo
Paano i-activate ang national roaming?
Paano paganahin ang Wi-Fi sa isang Acer laptop?
Ang pinakamabilis na internet sa mundo, ano ang bilis?