Softvaroj Dokumento pri Sekura Integriĝo pri 3D
Integriĝa Gvidilo 3D Sekura
Ekde la 01.01.2021 dufakta aŭtentokontrolo estos efektivigita kiel deviga postulo por ĉiuj transkomercaj kartaj pagaj transakcioj. Por plenumi ĉi tiun devon, la
telefonistoj de kreditkartaj retoj uzos la tiel nomatan proceduron 3D Secure. Por vi kiel komercisto, estas devige povi plenumi ĉi tiun procedon por viaj klientoj
01.01.2021. Poste vi trovos priskribon de la malsamaj manieroj de integriĝo kaj kiel la 3D Secure-proceduro devas esti efektivigita por ili.
Bonvolu elekti la integriĝan metodon, kiun vi uzas
- Ĉu vi uzas la kasformularon hCO?
- Ĉu vi uzas la kasformularon hPF?
- Ĉu vi prilaboras pagojn sen uzi formularon de la sistemo Unzer?
Bonvolu noti: Gravas ankaŭ laŭ kiu maniero debetoj aŭ antaŭrajtigoj (rezervoj) fariĝas. Eĉ se vi uzas pagilon de Unzer GmbH por la registrado de kartaj datumoj, la 3D Secure-procezo plenumiĝos sen kasformularo kiam la kartaj datumoj estos unuafoje debetitaj aŭ rajtigitaj. Ĉi-kaze validas la tria maniero de integriĝo sen formo provizita de Unzer.
Bonvolu noti ankaŭ:
Se vi uzas ripetajn pagojn (abonpagoj), nepre legu la sekcion "3D Sekura kaj Ripeta Pago".
3D Sekura proceduro kiam vi uzas la hCO-kasilon
La hCO-pago-formularo jam estas desegnita por la 3D Secure-proceduro. Vi ne bezonas plian agadon de via flanko por la efektivigo de la procedo. Tamen vi
devas certigi, ke via sistemo povas trakti la respondajn respondojn de nia pagsistemo, se la 3D Secure-procezo komenciĝos. En la nesinkrona respondo de la
paga sistemo al via servilo, la rezulto de la transakcio estas transdonita kaj devas esti taksata tie antaŭ reveno URL estas transdonita al la pagsistemo.
Tiucele la jenaj parametroj devas esti taksataj.
- PROCESADO.REVENO.KODO = 000.200.000
- PROCESSING.RETURN = Transakcio + pritraktata
- PROCESSING.RESULT = AKK
Klarigo: La stato de la transakcio estas "pritraktata", la parametro PROCESSING.RESULT
reprezentas nur antaŭan rezulton. Tiel longe kiel la 3D Sekura procezo efektivigas, la statuso
restu pritraktata.
La fina rezulto de la transakcio tiam estas ĉiu el ambaŭ
- PROCESADO.REVENO.KODO = 000.000.000
- PROCESSING.RESULT = AKK
or - PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 aŭ 000.200.000
- PROCESING.RESULT = NOK
En la unua kazo la transakcio sukcese finiĝis, en la dua kazo ĝi malsukcesis entute. Ĉi-lasta povas havi diversajn kialojn, inkluzive rifuzon aŭtentikigi. Vi faros
ricevi pli detalajn informojn en la parametroj "PROCESSING.RETURN" kaj "PROCESSING.RETURN.CODE".
Ni rekomendas, ke vi faru teston por ambaŭ mesaĝoj. Por pliaj informoj pri kiel fari teston kaj kiujn kreditkartajn detalojn vi povas uzi por testo, bonvolu vidi sube.
3D Sekura proceduro kiam vi uzas la hPF-kasilon
La pagilo de hPF ankaŭ estas desegnita por uzi la 3DS-proceduron jam. Vi ne bezonas plian agadon de via flanko por la efektivigo de la procedo. Kiel priskribite
por la hCO-efektivigo la respondo de la pagsistemo okazas en du paŝoj, tial via sistemo devas kontroli la valoron de la PROCESSING.RETURN.CODE
parametro dum prilaborado de la respondo.
Tiucele la jenaj parametroj devas esti taksataj.
- PROCESADO.REVENO.KODO = 000.200.000
- PROCESSING.RETURN = Transakcio + pritraktata
- PROCESSING.RESULT = AKK
Klarigo: La stato de la transakcio estas "pritraktata", la parametro PROCESSING.RESULT reprezentas nur antaŭan rezulton. Tiel longe kiel la 3D Sekura procezo efektivigas, la statuso
restu pritraktata.
La fina rezulto de la transakcio tiam estas ĉiu el ambaŭ
- PROCESADO.REVENO.KODO = 000.000.000
- PROCESSING.RESULT = AKK
or - PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 aŭ 000.200.000
- PROCESING.RESULT = NOK
En la unua kazo la transakcio sukcese finiĝis, en la dua kazo ĝi malsukcesis entute. Ĉi-lasta povas havi diversajn kialojn, inkluzive rifuzon aŭtentikigi. Vi faros
ricevi pli detalajn informojn en la parametroj "PROCESSING.RETURN" kaj "PROCESSING.RETURN.CODE".
Ni rekomendas, ke vi faru teston por ambaŭ mesaĝoj. Por pliaj informoj pri kiel fari teston kaj kiujn kreditkartajn detalojn vi povas uzi por testo, bonvolu vidi sube.
3D Sekura proceduro kun rekta konekto
Se vi ne uzas pagformon disponigitan de Unzer (antaŭe heidelpay) por prilabori kreditkartajn pagojn, aŭ se vi simple registras karton per unu el la formularoj kaj prilaboras la antaŭrajtigon (rezervon) aŭ debeton kiel referenco al la registrado kiel rekta komunikado kun la pagsistemo, vi devas efektivigi la procezon 3D Secure.
Nesinkrona transakcia fluo:
Ĉi tio estas nesinkrona procezo, en kiu via servilo ricevas plusendadon URL (Alidirektilo URL) de nia pagsistemo. Via servilo devas plusendi la klienton al ĉi tio URL por ke li povu plenumi la aŭtentikigon per 3D Secure-proceduro. La rezulto de ĉi tiu 3D-Sekura aŭtentikigo estas raportita rekte al Unzer de la karto-elsendanta banko.
Post sukcesa aŭtentokontrolo, la transakcio estas plue prilaborita en la Unzer-sistemo laŭ la maniero kiel vi jam scias sendante al via sistemo ĝeneralan rezulton fine, al kiu vi respondas
kun alidirektilo URL. La pagsistemo tiam redirektos la klienton al via sistemo per ĉi tiu alidirektilo URL de via sistemo
Bonvolu noti: En ĉi tiu laborfluo via sistemo ricevas du respondojn de la pagsistemo:
- Unu kun la stato "pritraktata" (PROCESSING.RETURN.CODE = 000.200.000 kaj PROCESSING.RETURN = Transakcio + pritraktata) kaj la alidirektilaj parametroj al la karto-elsendanta banko de la kliento.
- Unu kun la fina rezulto de la debeto aŭ rezervo. Estas ankaŭ du alidirektiloj URLMenciitaj en ĉi tiu procezo, unu el la pagsistemo, al kiu la kliento devas esti redirektita por aŭtentikigi ĉe sia karto-elsendanta banko kaj unu de via sistemo, ricevinte la finan rezulton, por redirekti la klienton en vian sistemon.
La sekvaj ŝanĝoj estos faritaj al la regula procedo. Bonvolu noti, ke pro la efektivigo de aliaj nesinkronaj pagmanieroj, kiel Paypal, iuj el ĉi tiuj
procezoj eble jam ekzistas en via efektivigo.
- Respondo URL
En la unua alvoko (n-ro 2 en la diagramo) al la pagsistemo, "Respondo URL”Devas esti transdonita en la frontend-grupo.
Bonvolu noti: La parametro IDENTIFICATION.REFERENCEID gravas nur se vi raportas al registrado aŭ alia jam ekzistanta transakcio - Traktanta Alidirektilo URL Se aŭtentikigo necesas, alidirektilo URL kaj aliaj parametroj en la alidirekta grupo estas transdonitaj en la respondo de la pagsistemo (n-ro 5 en la diagramo).
- Plusendo de la kliento al la alidirektilo URL
Se la alidirekta grupo respondas per alidirektilo URL, la retumilo de la kliento devas esti redirektita al ĉi tio URL (N-ro 6 en la diagramo) por plenumi aŭtentikigon. La aldonaj parametroj de la alidirekta grupo devas esti transdonitaj al la ekstera webretejo kiel POST-parametroj.
Bonvolu noti: Pliaj parametroj estas redonitaj en la grupo "PROCESSING.REDIRECT.xxx" nur kun 3D Secure Version 1 (eĉ tie la nombro kaj nomado povas varii), dum kun 3D Version 2 nur PROCESSING.REDIRECT.URL kiel montrita sube estas redonita: https://heidelpay.hpcgw.net/AuthService/v1/auth/public/2258_2863FFA4C5241C12E39F37
CCF / run Ĉi tio signifas, ke sendepende de la tipo kaj nombro de parametroj, la klienta retumilo devas redirekti al la PROCESSING.REDIRECT.URL.
Sube vi trovos simplan kodon eksample de kiel tia alidirektilo povas esti efektivigita. La parto celas informi finajn klientojn, kies sistemoj ne subtenas Ĝavaskripton aŭ malebligas ĝin. Ni forte rekomendas, ke la alidirektilo fariĝu en la aktiva retumila fenestro de la kliento kaj ne uzu fenestrojn aŭ novajn retumilajn fenestrojn, ĉar tio povus
inciti klientojn kaj konduki ilin fermi la paĝon al kiu ili estas redirektitaj.
- Nesinkrona rezultkontrolo
La rezulto de la aŭtentokontrolo estas sendita nesinkrone al via servilo. La pagsistemo atendas validan URL kiel respondo. (N-ro 12 & 13 en la diagramo). Por sukcesa aŭ malakceptita
pagoj, malsama URL respondeblas ĉi tie per via sistemo. - Revena vojo de la kliento
La pagsistemo redirektas la klienton al la URL provizita de la komerca sistemo post la aŭtentikiga procezo kaj la pagotransakcio finiĝis.
Bonvolu noti: Paŝoj 4.) kaj 5.) procedu tute same kiel vi jam konas en ekzistantaj NONE 3D Secure-transakcioj.
3D Sekura kaj Ripeta Pago
Ekde la 1-a de januaro 2021, 3D Secure estos deviga por ĉiuj retkomercaj kartaj transakcioj. Tamen, ĉar ĉi tio apenaŭ aplikeblas por ripetaj pagoj, la bankado
sistemoj havas apartan laborfluon por tio.
Tiucele la bankoj distingas
- CIT = kliento inicializis transakciojn
- MIT = komercisto pravalorizis transakciojn
La unua transakcio de karto en via komerca konto devas esti aŭtentikigita per 3D Secure ekde la 01.01.2021. Tia sukcesa aŭtentokontrolo estas deviga postulo en
por povi poste sendi pliajn rezervojn sur la sama karto sen 3D Secure. La kliento devas do esti plusendita al sia karto-elsendanta banko por la unua debeto en
laŭ la supre priskribita procedo kaj aŭtentikigas sin tie kiel la posedanto de la karto. Se debeto ne estas planita en la momento de la mendo, ekzamppro provperiodo, rezervo (antaŭ-rajtigo) de almenaŭ unu eŭro devas esti farita kun 3D Secure anstataŭe ĉe la ĉeesto de la kliento. Kapti ĉi tiun rezervon ne necesas.
Por ekzistantaj klientoj, tamen, neniu 3D-Sekura aŭtentikigo devas esti inventita. Se la unua sukcesa debeto okazis antaŭ la 01.01.2021, la klienta registro ankaŭ povas esti supozita
estis sukcese aŭtentikigitaj. Por novaj klientoj ekde la 01.01.2021, aliflanke, 3D Secure-aŭtentikigo estas deviga por la unua debeto aŭ rezervo (antaŭ-rajtigo).
Bonvolu noti: Tiurilate la banka sistemo rigardas la kartajn datumojn, ne la klientajn datumojn. Do se ekzistanta kliento uzas novan karton post 01.01.2021, ekzample ĉar la antaŭa
unu eksvalidiĝis aŭ ĉar li ŝanĝis sian kart-emisian bankon, jen nova ripetiĝanta ciklo de la banka punkto de view kaj devas esti aŭtentikigita per 3D Secure por la unua rezervo.
Post kiam ĉi tiu komenca aŭtentikigo sukcese efektivigas, ĉiuj pliaj transakcioj estas esceptitaj de la devo uzi 3D Secure. La antaŭkondiĉoj por ripetiĝanta pago sen 3D Secure estas do:
- Estas almenaŭ unu sukcesa debeto aŭ rezervo (antaŭ-rajtigo), kiu estis realigita per 3D Secure aŭ okazis antaŭ la 01.01.2021.
- ĝi estas referencita al ekzistanta registriĝo kaj debeto post sendado
Por sciigi la pagsistemon, ke temas pri ripetiĝanta pago, la parametro RECURRENCE.MODE = REPETITA devas esti sendita ankaŭ. Ĉi tio signas al la sistemo, ke a
ripetiĝanta pago estas raportota al la bankaj sistemoj.
Bonvolu noti: Se la parametro RECURRENCE.MODE = REPEATED estas enigita kiam nova karto estas ŝarĝita por la unua fojo, 3D Secure plusendado estos efektivigita malgraŭ ĉi tiu parametro.
Testado de la 3D Sekura efektivigo
Vi povas provi la 3D Secure-ligon iam ajn per nia pagsistemo. Por fari tion, uzu la reĝimon "CONNECTOR_TEST" por transakcio, kiel montrite en la ekzamples supre.
Konektaj datumoj por ĉi tiu testo:
| SECURITY.SENDER | 31HA07BC8142C5A171745D00AD63D182 |
| UZANTO.LOGIN | 31ha07bc8142c5a171744e5aef11ffd3 |
| USER.PWD | 93167DE7 |
| TRANSAKCIO.KANALO | 31HA07BC8142C5A171749A60D979B6E4 |
| Moneroj agorditaj por 3D Versio 2 | EUR, USD, SEK |
| Moneroj agorditaj por 3D Versio 1 | GBP, CZK, CHF |
Sistema enireja finaĵo estas ĉiu el ambaŭ
SGW-enirejo:
- https://test-heidelpay.hpcgw.net/sgw/gtw - Latin-15 kodita
- https://test-heidelpay.hpcgw.net/sgw/gtwu - UTF-8 kodita
NGW-enirejo:
- https://test-heidelpay.hpcgw.net/ngw/post
Kreditkartaj datumoj por ĉi tiu testo:
| markoj | kartonombroj | CVV | limdato | notu |
| MasterCard | 5453010000059543 | 123 | estonta dato | 3D - pasvorto: sekreta3 |
| Vizo | 4711100000000000 | 123 | estonta dato | 3DS - pasvorto: sekreta! |
Bonvolu noti: Por 3D Secure Version 2, vi ne bezonas enigi pasvorton, sed simple alklaku la ligon "Alklaku ĉi tie por kompletigi aŭtentikigon.
La sola maniero simuli eraron per 3D Secure Version 2 estas lasi la paĝon kun la ligilo eksvalidiĝi (ĉ. 18 minutoj).
Legu pli pri ĉi tiu manlibro kaj elŝutu PDF:
Dokumentoj/Rimedoj
 |
Programaroj 3D Sekura Integriga Gvidilo [pdfDokumentaro Unzer, Integriĝa Gvidilo, 3D Secure |
