Softwares 3D Secure Integration Guide Dokumentasie

Integrasiegids 3D Veilig

Vanaf 01.01.2021 sal tweefaktor-verifikasie geïmplementeer word as 'n verpligte vereiste vir alle e-handelkaartbetalingstransaksies. Ten einde aan hierdie verpligting te voldoen, moet die
bestuurders van kredietkaartnetwerke sal die sogenaamde 3D Secure-prosedure gebruik. Dit is vir u as handelaar verpligtend om hierdie prosedure vir u klante te kan uitvoer
01.01.2021. Hierna volg 'n beskrywing van die verskillende maniere van integrasie en hoe die 3D Secure-prosedure daarvoor geïmplementeer moet word.

Kies die integrasiemetode wat u gebruik

  • Gebruik u die afmeldvorm hCO?
  • Gebruik u die afrekeningsvorm hPF?
  • Verwerk u betalings sonder om 'n vorm wat deur die Unzer-stelsel verskaf word, te gebruik?

Neem asseblief kennis: Dit is ook belangrik op watter wyse debiteure of voorafmagtigings (besprekings) gemaak word. Selfs as u 'n betalingsvorm van Unzer GmbH gebruik vir die registrasie van kaartgegewens, sal die 3D Secure-proses sonder 'n afrekeningsvorm uitgevoer word wanneer die kaartdata vir die eerste keer gedebiteer of gemagtig word. In hierdie geval geld die derde manier van integrasie sonder 'n vorm wat deur Unzer verskaf word.

Let ook op:
Lees die afdeling “3D Veilige en Herhalende Betaling” as u herhalende betalings (intekenaarbetalings) gebruik.

3D Secure-prosedure wanneer u die hCO-afrekeningsvorm gebruik

Die hCO-afrekeningsvorm is reeds ontwerp vir die 3D Secure-prosedure. Daar is geen addisionele optrede van u kant nodig vir die implementering van die prosedure nie. U egter
moet u seker maak dat u stelsel die ooreenstemmende antwoorde van ons betaalstelsel kan hanteer indien die 3D Secure-proses begin word. In die asynchrone reaksie van die
betaalstelsel na u bediener gestuur word, word die resultaat van die transaksie versend en moet dit voor die terugkeer daar geëvalueer word URL word na die betalingstelsel oorgedra.

Vir hierdie doel moet die volgende parameters geëvalueer word.

  • VERWERKING.RETURN.CODE = 000.200.000
  • PROCESSING.RETURN = Transaksie + hangende
  • VERWERKING.RESULT = REKENING

Verduideliking: die status van die transaksie is 'hangende', die parameter VERWERKING.RESULTAT
verteenwoordig slegs 'n voorlopige uitslag. Solank die 3D Secure-proses uitgevoer word, is die status
hangende bly.

Die finale resultaat van die transaksie is dan ook

  •  VERWERKING.RETURN.CODE = 000.000.000
  • VERWERKING.RESULT = REKENING
    or
  • PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 oder 000.200.000
  • VERWERKING.RESULTAT = NOK

In die eerste geval is die transaksie suksesvol voltooi, in die tweede geval het die transaksie in die geheel misluk. Laasgenoemde kan verskillende redes hê, waaronder 'n weiering om te verifieer. Jy sal
ontvang meer gedetailleerde inligting in die parameters “PROCESSING.RETURN” en “PROCESSING.RETURN.CODE”.
Ons beveel aan dat u 'n toets vir albei boodskappe doen. Vir meer inligting oor hoe om 'n toets te doen en watter kredietkaartbesonderhede u vir 'n toets kan gebruik, sien hieronder.

3D Secure-prosedure wanneer u die hPF-afhandelingvorm gebruik

Die hPF-afhandelingvorm is ook ontwerp om die 3DS-prosedure reeds te gebruik. Daar is geen addisionele optrede van u kant nodig vir die implementering van die prosedure nie. Soos beskryf
vir die hCO-implementering vind die reaksie van die betalingstelsel in twee stappe plaas, daarom moet u stelsel die waarde van die VERWERKING nagaan.
parameter wanneer die antwoord verwerk word.

Vir hierdie doel moet die volgende parameters geëvalueer word.

  • VERWERKING.RETURN.CODE = 000.200.000
  • PROCESSING.RETURN = Transaksie + hangende
  • VERWERKING.RESULT = REKENING

Verduideliking: die status van die transaksie is "hangende", die parameter VERWERKING.RESULTA verteenwoordig slegs 'n voorlopige resultaat. Solank die 3D Secure-proses uitgevoer word, is die status
hangende bly.

Die finale resultaat van die transaksie is dan ook

  • VERWERKING.RETURN.CODE = 000.000.000
  • VERWERKING.RESULT = REKENING
    or
  • PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 oder 000.200.000
  • VERWERKING.RESULTAT = NOK

In die eerste geval is die transaksie suksesvol voltooi, in die tweede geval het die transaksie in die geheel misluk. Laasgenoemde kan verskillende redes hê, waaronder 'n weiering om te verifieer. Jy sal
ontvang meer gedetailleerde inligting in die parameters “PROCESSING.RETURN” en “PROCESSING.RETURN.CODE”.
Ons beveel aan dat u 'n toets vir albei boodskappe doen. Vir meer inligting oor hoe om 'n toets te doen en watter kredietkaartbesonderhede u vir 'n toets kan gebruik, sien hieronder.

3D Veilige prosedure met direkte verbinding

As u nie 'n betaalvorm wat deur Unzer (voorheen heidelpay) verskaf is, gebruik om kredietkaartbetalings te verwerk nie, of as u slegs 'n kaart registreer met behulp van een van die vorms en die voorafgoedkeuring (bespreking) of debiet verwerk as verwysing na die registrasie as direkte kommunikasie met die betaalstelsel, moet u die 3D Secure-proses implementeer.

Asynchrone transaksievloei:

Dit is 'n asynchrone proses waarin u bediener 'n aanstuur ontvang URL (Herlei URL) vanaf ons betaalstelsel. U bediener moet die kliënt hierna aanstuur URL sodat hy die verifikasie kan uitvoer via die 3D Secure-prosedure. Die resultaat van hierdie 3D Secure-verifikasie word direk aan Unzer gerapporteer deur die bank wat die kaart uitreik.

Na suksesvolle verifikasie word die transaksie verder verwerk in die Unzer-stelsel soos u dit al ken, deur aan die einde 'n algehele resultaat aan u stelsel te stuur waarop u antwoord
met 'n aanstuur URL. Die betaalstelsel lei dan die klant weer na u stelsel met behulp van hierdie aanstuur URL vanaf u stelsel

Let wel: in hierdie werkstroom ontvang u stelsel twee antwoorde van die betaalstelsel:

- Een met die status “hangende” (PROCESSING.RETURN.CODE = 000.200.000 en PROCESSING.RETURN = Transaksie + hangende) en die aanstuurparameters na die kaartuitreikende bank van die klant
- Een met die finale resultaat van die debiet of bespreking. Daar is ook twee omleidings URLs genoem in hierdie proses, een van die betalingstelsel waarheen die klant moet herlei word om by sy kaartuitreikende bank en een van u stelsel te verifieer, wanneer die finale resultaat ontvang word, om die klant weer na u stelsel te lei.

tydlyn

Die volgende wysigings sal aan die gewone prosedure aangebring word. Let daarop dat sommige van hierdie as gevolg van die implementering van ander asynchrone betaalmetodes, soos Paypal
prosesse bestaan ​​moontlik al in u implementering.

  1. Reaksie URL
    In die eerste oproep (nr. 2 in die diagram) na die betaalstelsel, 'n “Antwoord URL”Moet in die frontend-groep geslaag word.
    grafiese gebruikerskoppelvlak, teks, toepassing
    Neem asseblief kennis: Die parameter IDENTIFICATION.REFERENCEID is slegs relevant as u na 'n registrasie of 'n ander bestaande transaksie verwys
  2. Verwerk herleiding URL As verifikasie benodig word, word 'n aanstuur URL en ander parameters in die aanstuurgroep word oorgedra in die antwoord vanaf die betalingstelsel (nr. 5 in die diagram).
    grafiese gebruikerskoppelvlak, teks
    grafiese gebruikerskoppelvlak, teks, toepassing, letter
  3. Aanstuur van die klant na die omleiding URL
    As die aanstuurgroep reageer met 'n aanstuur URL, moet die kliënt se blaaier hierna herlei word URL (Nr. 6 in die diagram) om verifikasie uit te voer. Die bykomende parameters van die herleidingsgroep moet na die eksterne oorgedra word webwebwerf as POST -parameters.
    Let wel: bykomende parameters word slegs in 3D Secure weergawe 1 in die groep “PROCESSING.REDIRECT.xxx” teruggestuur (selfs daar kan die nommer en benaming verskil), terwyl dit by 3D Version slegs 'n VERWERKING.REDIRECT is.URL soos hieronder getoon, word teruggestuur: https://heidelpay.hpcgw.net/AuthService/v1/auth/public/2258_2863FFA4C5241C12E39F37
    CCF / run Dit beteken dat die kliëntblaaier, ongeag die tipe en aantal parameters, na die PROCESSING.REDIRECT moet herlei.URL.
    Hieronder vind u 'n eenvoudige kode, bvample van hoe so 'n herleiding uitgevoer kan word. Die deel is bedoel om eindklante in kennis te stel wie se stelsels Javascript nie ondersteun of dit uitskakel nie. Ons beveel ten sterkste aan dat die herleiding in die aktiewe blaaiervenster van die kliënt plaasvind, en nie om pop -upvensters of nuwe blaaiervensters te gebruik nie, aangesien dit
    irriteer klante en lei hulle om die bladsy te sluit waarna hulle herlei word.
    teks, brief
  4. Asynchrone resultaatkontrole
    Die resultaat van die verifikasie word asynchroon na u bediener gestuur. Die betalingstelsel verwag 'n geldige URL as reaksie. (Nr. 12 & 13 in die diagram). Vir suksesvol of verwerp
    betalings, 'n ander URL kan hier deur u stelsel beantwoord word.
  5. Terugkeer van die klant
    Die betalingstelsel lei die klant na die URL verskaf deur die handelaarstelsel nadat die verifikasieproses en die betalingstransaksie afgehandel is.
    Let wel: stappe 4.) en 5.) gaan presies op dieselfde manier as wat u al in bestaande NONE 3D Secure-transaksies ken.

3D veilige en herhalende betaling

1D Secure is vanaf 2021 Januarie 3 verpligtend vir alle transaksies met e-handel. Aangesien dit egter skaars van toepassing is op herhalende betalings, kan die bankwese
stelsels het 'n aparte werkvloei hiervoor.

Vir hierdie doel onderskei die banke tussen

  • CIT = transaksies wat deur die klant geïnitialiseer is
  • MIT = handelaars geïnitialiseerde transaksies

Die eerste transaksie van 'n kaart in u handelaarrekening moet vanaf 3 met 01.01.2021D Secure geverifieer word. So 'n suksesvolle verifikasie is 'n verpligte vereiste in
om daarna sonder 3D Secure verdere besprekings op dieselfde kaart te kan indien. Die kliënt moet dus vir die eerste debitering na sy bankuitreikende bank gestuur word
volgens die prosedure hierbo beskryf en verifieer homself daar as die kaarthouer. As 'n debiet ten tyde van die bestelling nie beplan word nie, bvampAs gevolg van 'n proeftydperk, moet 'n bespreking (vooraf goedkeuring) van ten minste een euro met 3D Secure in plaas van die kliënt gemaak word. Hierdie bespreking is nie nodig nie.

Vir bestaande klante hoef daar egter geen 3D Secure-verifikasie opgemaak te word nie. As die eerste suksesvolle debitering voor 01.01.2021 plaasgevind het, kan ook aanvaar word dat die klant se rekord is
suksesvol geverifieer. Vir nuwe klante, vanaf 01.01.2021, is 3D Secure-verifikasie daarenteen verpligtend vir die eerste debitering of bespreking (voorafmagtiging).

Let wel: In hierdie opsig kyk die bankstelsel na die kaartdata, nie na die kliëntedata nie. As 'n bestaande klant dus na 01.01.2021 'n nuwe kaart gebruik, bvample omdat die vorige
een verval het, of omdat hy sy bank-uitreikende bank verander het, is dit 'n nuwe herhalende siklus uit die oogpunt van die banke view en moet vir die eerste bespreking met 3D Secure geverifieer word.

Sodra hierdie aanvanklike verifikasie suksesvol uitgevoer is, is alle verdere transaksies vrygestel van die verpligting om 3D Secure te gebruik. Die voorvereistes vir herhalende betaling sonder 3D Secure is dus:

  • Daar is ten minste een suksesvolle debiet- of bespreking (voorafmagtiging) wat met 3D Secure uitgevoer is of voor 01.01.2021 plaasgevind het.
  • daar word na indiening na 'n bestaande registrasie en debiet verwys

Om die betalingstelsel te laat weet dat dit 'n herhalende betaling is, moet die parameter RECURRENCE.MODE = HERHAAL ook gestuur word. Dit dui aan die stelsel dat a
Herhalende betaling moet aan die bankstelsels gerapporteer word.

Let wel: as die parameter RECURRENCE.MODE = HERHAAL ingevoer word wanneer 'n nuwe kaart vir die eerste keer gelaai word, sal 3D Secure deurstuur ondanks hierdie parameter uitgevoer word.

Toets die 3D Secure implementering

U kan die 3D Secure -verbinding te eniger tyd via ons betaalstelsel toets. Om dit te doen, gebruik die modus "CONNECTOR_TEST" vir 'n transaksie, soos getoon in die vorigeamples hierbo.
Verbindingsdata vir hierdie toets:

  SEKURITEIT   31HA07BC8142C5A171745D00AD63D182
  GEBRUIKER AANMELDING   31ha07bc8142c5a171744e5aef11ffd3
  GEBRUIKER.PWD   93167DE7
  TRANSAKSIE.KANAAL   31HA07BC8142C5A171749A60D979B6E4
  Geldeenhede ingestel vir 3D weergawe 2   EUR, USD, SEK
  Geldeenhede ingestel vir 3D weergawe 1   GBP, CZK, CHF

Die eindpunt van die stelselpoort is óf
SGW-poort:
- https://test-heidelpay.hpcgw.net/sgw/gtw - Latin-15 gekodeer
- https://test-heidelpay.hpcgw.net/sgw/gtwu - UTF-8 gekodeer
NGW-poort:
- https://test-heidelpay.hpcgw.net/ngw/post

Kredietkaartdata vir hierdie toets:

  handelsmerke   kaartnommers   CVV   vervaldatum   nota
  MasterCard   5453010000059543   123   toekomstige datum   3D - wagwoord: geheim3
  Visa   4711100000000000   123   toekomstige datum   3DS - wagwoord: geheim! 33

Let wel: vir 3D Secure weergawe 2 hoef u nie 'n wagwoord in te voer nie, maar kliek op die skakel. 'Klik hier om die verifikasie te voltooi.
Die enigste manier om 'n fout met 3D Secure Weergawe 2 te simuleer, is om die bladsy met die skakel uit te laat (ongeveer 18 minute).

 

Lees meer oor hierdie handleiding en laai PDF af:

Dokumente / Hulpbronne

Sagteware 3D Veilige Integrasie Gids [pdfDokumentasie
Unzer, integrasiegids, 3D Secure

Verwysings

Los 'n opmerking

Jou e-posadres sal nie gepubliseer word nie. Vereiste velde is gemerk *