Documentació de la Guia d'integració de programaris 3D Secure
Guia d'integració 3D Secure
A partir de l'01.01.2021, l'autenticació de dos factors s'implementarà com a requisit obligatori per a totes les transaccions de pagament amb targeta de comerç electrònic. Per complir amb aquesta obligació, el
els operadors de xarxes de targetes de crèdit utilitzaran l'anomenat procediment 3D Secure. Per a tu com a comerciant és obligatori poder realitzar aquest tràmit per als teus clients des de
01.01.2021/3/XNUMX. A continuació trobareu una descripció de les diferents maneres d'integració i com s'ha d'implementar el procediment XNUMXD Secure per a elles.
Seleccioneu el mètode d'integració que feu servir
- Estàs utilitzant el formulari de pagament hCO?
- Estàs utilitzant el formulari de pagament hPF?
- Processeu els pagaments sense utilitzar un formulari proporcionat pel sistema Unzer?
Tingueu en compte: També és important de quina manera es fan els dèbits o preautoritzacions (reserves). Fins i tot si utilitzeu un formulari de pagament d'Unzer GmbH per al registre de les dades de la targeta, el procés 3D Secure es durà a terme sense formulari de pagament quan les dades de la targeta es debiten o s'autoritzen per primera vegada. En aquest cas s'aplica la tercera via d'integració sense formulari proporcionat per Unzer.
Tingueu en compte també:
Si utilitzeu pagaments recurrents (pagaments de subscripció), assegureu-vos de llegir la secció "Pagament 3D Secure i recurrent".
Procediment 3D Secure quan s'utilitza el formulari de pagament hCO
El formulari de pagament de hCO ja està dissenyat per al procediment 3D Secure. No hi ha cap acció addicional del vostre costat necessària per a la implementació del procediment. Tanmateix, tu
t'has d'assegurar que el teu sistema pot gestionar les respostes corresponents del nostre sistema de pagament en cas que s'iniciï el procés 3D Secure. En la resposta asíncrona de la
sistema de pagament al vostre servidor, el resultat de la transacció es transmet i s'ha d'avaluar allí abans d'una devolució URL es transmet al sistema de pagament.
Per a això s'han d'avaluar els paràmetres següents.
- CODI.DEVOLUCIÓ.PROCESSANT = 000.200.000
- PROCESSING.RETURN = Transacció+pendent
- PROCESSING.RESULT = ACK
Explicació: L'estat de la transacció és “pendent”, el paràmetre PROCESSING.RESULT
representa només un resultat preliminar. Mentre es dugui a terme el procés 3D Secure, l'estat
romanen pendents.
El resultat final de la transacció és llavors
- CODI.DEVOLUCIÓ.PROCESSANT = 000.000.000
- PROCESSING.RESULT = ACK
or - PROCESSING.RETURN.CODE = entre 000.000.000 o 000.200.000
- PROCESSING.RESULT = NOK
En el primer cas, la transacció s'ha completat amb èxit, en el segon cas ha fallat en general. Aquest últim pot tenir diverses raons, inclosa la negativa a autenticar-se. Ho faràs
rebre informació més detallada als paràmetres “PROCESSING.RETURN” i “PROCESSING.RETURN.CODE”.
Us recomanem que feu una prova per als dos missatges. Per obtenir més informació sobre com fer una prova i quins detalls de la targeta de crèdit podeu utilitzar per a una prova, consulteu a continuació.
Procediment 3D Secure quan s'utilitza el formulari de pagament hPF
El formulari de pagament de hPF també està dissenyat per utilitzar ja el procediment 3DS. No hi ha cap acció addicional del vostre costat necessària per a la implementació del procediment. Com està descrit
per a la implementació de hCO, la resposta del sistema de pagament es fa en dos passos, per això el vostre sistema ha de comprovar el valor del CODI.PROCESSING.RETURN.
paràmetre en processar la resposta.
Per a això s'han d'avaluar els paràmetres següents.
- CODI.DEVOLUCIÓ.PROCESSANT = 000.200.000
- PROCESSING.RETURN = Transacció+pendent
- PROCESSING.RESULT = ACK
Explicació: L'estat de la transacció és "pendent", el paràmetre PROCESSING.RESULT representa només un resultat preliminar. Mentre es dugui a terme el procés 3D Secure, l'estat
romanen pendents.
El resultat final de la transacció és llavors
- CODI.DEVOLUCIÓ.PROCESSANT = 000.000.000
- PROCESSING.RESULT = ACK
or - PROCESSING.RETURN.CODE = entre 000.000.000 o 000.200.000
- PROCESSING.RESULT = NOK
En el primer cas, la transacció s'ha completat amb èxit, en el segon cas ha fallat en general. Aquest últim pot tenir diverses raons, inclosa la negativa a autenticar-se. Ho faràs
rebre informació més detallada als paràmetres “PROCESSING.RETURN” i “PROCESSING.RETURN.CODE”.
Us recomanem que feu una prova per als dos missatges. Per obtenir més informació sobre com fer una prova i quins detalls de la targeta de crèdit podeu utilitzar per a una prova, consulteu a continuació.
Procediment 3D Secure amb connexió directa
Si no utilitzeu un formulari de pagament proporcionat per Unzer (anteriorment heidelpay) per processar pagaments amb targeta de crèdit, o si simplement registreu una targeta mitjançant un dels formularis i processeu la preautorització (reserva) o el dèbit com a referència al registre com a comunicació directa amb el sistema de pagament, cal implementar el procés 3D Secure.
Flux de transaccions asíncrons:
Aquest és un procés asíncron en el qual el vostre servidor rep un reenviament URL (Redirecció URL) del nostre sistema de pagament. El vostre servidor ha de reenviar el client a això URL perquè pugui realitzar l'autenticació mitjançant procediment 3D Secure. El resultat d'aquesta autenticació 3D Secure s'informa directament a Unzer pel banc emissor de la targeta.
Després de l'autenticació correcta, la transacció es processa al sistema Unzer de la manera que ja sabeu enviant al vostre sistema un resultat global al final, al qual responeu.
amb una redirecció URL. Aleshores, el sistema de pagament redirigirà el client al vostre sistema mitjançant aquesta redirecció URL del vostre sistema
Tingueu en compte: en aquest flux de treball, el vostre sistema rep dues respostes del sistema de pagament:
– Un amb l'estat “pendent” (PROCESSING.RETURN.CODE=000.200.000 i PROCESSING.RETURN=Transacció+pendent) i els paràmetres de redirecció al banc emissor de la targeta del client
– Un amb el resultat final del dèbit o reserva. També hi ha dues redireccions URLS'esmenten en aquest procés, un del sistema de pagament al qual s'ha de redirigir el client per autenticar-se al banc emissor de la seva targeta i un del vostre sistema, en rebre el resultat final, per redirigir el client al vostre sistema.
Es faran els següents canvis al procediment habitual. Tingueu en compte que a causa de la implementació d'altres mètodes de pagament asíncrons, com Paypal, alguns d'aquests
És possible que ja existeixin processos a la vostra implementació.
- Resposta URL
En la primera trucada (núm.2 a l'esquema) al sistema de pagament, una “Resposta URL” s'ha de passar al grup d'interfície.
Tingueu en compte: El paràmetre IDENTIFICATION.REFERENCEID només és rellevant si feu referència a un registre o a una altra transacció ja existent - Processament de la redirecció URL Si es requereix autenticació, una redirecció URL i altres paràmetres del grup de redirecció es transfereixen a la resposta del sistema de pagament (núm. 5 al diagrama).
- Reenviament del client a la redirecció URL
Si el grup de redirecció respon amb una redirecció URL, el navegador del client s'ha de redirigir a aquest URL (núm. 6 del diagrama) per realitzar l'autenticació. Els paràmetres addicionals del grup de redirecció s'han de transferir a l'extern weblloc com a paràmetres POST.
Tingueu en compte: els paràmetres addicionals es retornen al grup "PROCESSING.REDIRECT.xxx" només amb la versió 3 de 1D Secure (fins i tot allà el nombre i la denominació poden variar), mentre que amb la versió 3 de 2D només un PROCESSING.REDIRECT.URL es retorna tal com es mostra a continuació: https://heidelpay.hpcgw.net/AuthService/v1/auth/public/2258_2863FFA4C5241C12E39F37
CCF/run Això vol dir que independentment del tipus i nombre de paràmetres, el navegador client ha de redirigir a PROCESSING.REDIRECT.URL.
A continuació trobareu un codi senzill exampde com es pot executar aquesta redirecció. El part està destinada a informar els clients finals els sistemes dels quals no admeten Javascript o el tenen desactivat. Recomanem fermament que la redirecció es faci dins de la finestra activa del navegador del client i que no utilitzeu finestres emergents o finestres noves del navegador, ja que això podria
irritar els clients i portar-los a tancar la pàgina a la qual són redirigits.
- Comprovació de resultats asíncrons
El resultat de l'autenticació s'envia de manera asíncrona al vostre servidor. El sistema de pagament espera un vàlid URL com a resposta. (Núm. 12 i 13 al diagrama). Per reeixit o rebutjat
pagaments, una altra URL el vostre sistema pot respondre aquí. - Ruta de retorn del client
El sistema de pagament redirigeix el client al URL proporcionat pel sistema del comerciant després de completar el procés d'autenticació i la transacció de pagament.
Tingueu en compte: els passos 4.) i 5.) continuen exactament de la mateixa manera que ja esteu familiaritzat amb les transaccions NONE 3D Secure existents.
Pagament 3D segur i recurrent
A partir de l'1 de gener de 2021, 3D Secure serà obligatori per a totes les transaccions amb targeta de comerç electrònic. No obstant això, com que això gairebé no és aplicable als pagaments recurrents, la banca
Els sistemes tenen un flux de treball independent per a això.
Amb aquesta finalitat, els bancs distingeixen entre
- CIT = transaccions inicialitzades pel client
- MIT = transaccions inicialitzades del comerciant
La primera transacció d'una targeta al vostre compte de comerciant s'ha d'autenticar amb 3D Secure a partir de l'01.01.2021. Aquesta autenticació reeixida és un requisit obligatori
per poder enviar posteriorment més reserves amb la mateixa targeta sense 3D Secure. Per tant, el client s'ha de reenviar al banc emissor de la targeta per al primer dèbit
d'acord amb el procediment descrit anteriorment i s'autentica com a titular de la targeta. Si no està previst un dèbit en el moment de la comanda, per exampa causa d'un període de prova, s'ha de fer una reserva (preautorització) d'almenys un euro amb 3D Secure en presència del client. No cal captar aquesta reserva.
Tanmateix, per als clients existents, no cal crear cap autenticació 3D Secure. Si el primer dèbit satisfactori es va realitzar abans de l'01.01.2021, també es pot suposar que el registre del client és
s'han autenticat correctament. Per als nous clients a partir de l'01.01.2021, en canvi, l'autenticació 3D Secure és obligatòria per al primer dèbit o reserva (preautorització).
Tingueu en compte: en aquest sentit, el sistema bancari mira les dades de la targeta, no les dades del client. Així, si un client existent utilitza una targeta nova després de l'01.01.2021, per exempleample perquè l'anterior
un ha caducat o perquè ha canviat el banc emissor de la targeta, aquest és un nou cicle recurrent des del punt de partida dels bancs. view i s'ha d'autenticar amb 3D Secure per a la primera reserva.
Un cop realitzada amb èxit aquesta autenticació inicial, totes les transaccions posteriors queden exemptes de l'obligació d'utilitzar 3D Secure. Per tant, els requisits previs per al pagament recurrent sense 3D Secure són:
- Hi ha almenys un dèbit o reserva (preautorització) que s'ha dut a terme amb 3D Secure o que s'ha fet abans de l'01.01.2021/XNUMX/XNUMX.
- es fa referència a un registre i domiciliació existents en el moment de la presentació
Perquè el sistema de pagament sàpiga que es tracta d'un pagament recurrent, també s'ha d'enviar el paràmetre RECURRENCE.MODE=REPEATED. Això indica al sistema que a
el pagament recurrent s'ha d'informar als sistemes bancaris.
Si us plau, tingueu en compte: si s'introdueix el paràmetre RECURRENCE.MODE=REPEATED quan es carrega una targeta nova per primera vegada, es realitzarà el reenviament 3D Secure malgrat aquest paràmetre.
Prova de la implementació de 3D Secure
Pots provar la connexió 3D Secure en qualsevol moment mitjançant el nostre sistema de pagament. Per fer-ho, utilitzeu el mode "CONNECTOR_TEST" per a una transacció, tal com es mostra a l'examples més amunt.
Dades de connexió per a aquesta prova:
| SEGURETAT.REMITENT | 31HA07BC8142C5A171745D00AD63D182 |
| ENTRADA D'USUARI | 31ha07bc8142c5a171744e5aef11ffd3 |
| USUARI.PWD | 93167DE7 |
| TRANSACCIÓ.CHANNEL | 31HA07BC8142C5A171749A60D979B6E4 |
| Monedes configurades per a la versió 3 de 2D | EUR, USD, SEK |
| Monedes configurades per a la versió 3 de 1D | GBP, CZK, CHF |
El punt final de la passarel·la del sistema ho és
Passarel·la SGW:
– https://test-heidelpay.hpcgw.net/sgw/gtw – Codificació en llatí-15
– https://test-heidelpay.hpcgw.net/sgw/gtwu – Codificat UTF-8
Passarel·la NGW:
– https://test-heidelpay.hpcgw.net/ngw/post
Dades de la targeta de crèdit per a aquesta prova:
| marques | números de targeta | CVV | data de caducitat | nota |
| MasterCard | 5453010000059543 | 123 | data futura | 3D – contrasenya: secret3 |
| Visa | 4711100000000000 | 123 | data futura | 3DS – contrasenya: secret!33 |
Tingueu en compte: per a la versió 3 de 2D Secure, no cal que introduïu una contrasenya, sinó que simplement feu clic a l'enllaç "Feu clic aquí per completar l'autenticació.
L'única manera de simular un error amb 3D Secure Versió 2 és deixar que la pàgina amb l'enllaç s'acabi el temps d'espera (uns 18 minuts).
Llegeix més sobre aquest manual i baixa el PDF:
Documents/Recursos
 |
Guia d'integració de programari 3D Secure [pdfDocumentació Unzer, Guia d'integració, 3D Secure |
