e-gold
Shopping Cart Interface

Leírás

 

 

 

 

 

 

 

2004 szeptember 30.

 

 

Copyright 1998-2004 by e-gold Ltd.

website: http://www.e-gold.com

Bevezetés.. 1

1.1       Kinek szól?. 1

1.2       Terminológia.. 1

1.3       Az e-gold Shopping Cart Interfész áttekintése. 1

1.3.1        Azonosítás. 1

1.3.2        Célok. 1

1.3.3        Implementáció. 2

A Shopping Cart Interfész részletes leírása  . 4

1.4       AZ e-gold FIZETÉSI RENDSZER belépő FORMJAi... 4

1.4.1        Az AKCIÓ belépő form.. 5

1.4.2        A belépő form METHOD beállítása.. 5

1.4.3        A rejtett szöveg mezők a belépő formon. 5

1.4.3.1     A kötelező és a formhoz kapcsolódó opciónális rejtett szövegmezők. 5

1.4.3.2     Opcionális kereskedő specifikus rejtett  szövegmezők. 8

1.5       A vásárló kapcsolódása az e-gold Fizetési rendszerhez... 10

2.1       Az e-gold Fizetési rendszer kapcsolata a kereskedő rendszeréhez... 12

2.1.1        A kereskedő rendszerének elküldött formok.. 13

2.1.1.1     Fizetési tranakció form.. 14

2.1.1.1.1    Az MD5 Hash érték. 16

2.1.1.2     A vásárló normál visszaérkező formja.. 17

2.1.1.3     A vásárló alternatív visszaérkező formja.. 18

Minta formok. 18

2.2       az  e-gold fizetési rendszerbe  belépő mintaform ... 19

2.3       fizetési tranzakció mintaForm... 21

2.4       vásárló normál visszatérő mintaForm... 21

2.5       vásárló Alternatív visszatérő mintaForm... 22

Az Ön e-gold Shopping Cart Interfészének a tesztje.. 23

2.6       Az Ön sC interfészének tesztelési módszereinek kezdőbeállítása

2.7       Implementációs irányvonalak. 23

2.8       biztonsági irányvonalak. 23

 

 

1. ábra: A Shopping Cart Interfész egyszerűsített ábrázolása.................................................. 3

2. ábra: Az SCI felülnézeti vázlata......................................................................................... 4

3. ábra: Fizetési utalvány mintaform..................................................................................... 11

4. ábra: Fizetési megerősítés mintaoldal............................................................................... 12

5. ábra: HTML belépési mintaform...................................................................................... 20

6. ábra: Fizetési tranzakció mintaform.................................................................................. 21

7. ábra: Vásárló normál visszatérő mintaform....................................................................... 22

8. ábra: Vásárló alternatív visszatérő mintaform.................................................................... 22

 

A táblázatok listája

 

1. táblázat: A kötelező és a formhoz kapcsolódó opcionális rejtett szöveg mezők..................................... 8

2. táblázat: A támogatott fizetési egységek............................................................................................... 9

3. táblázat: Fizetési fémek...................................................................................................................... 10

4. táblázat: A kereskedő rendszerének visszaküldött formok................................................................... 13

5. táblázat: Azon rejtett szövegmezők, melyek mindig jelen vannak a fizetési trazakciós formon................ 16

6. táblázat: Azon rejtett szövegmezők, melyek mindig jelen vannak a vásárló normál visszetérő formon.... 18

7. táblázat: Azon rejtett szövegmezők, melyek mindig jelen vannak a vásárló alternatív visszetérő formon. 18

Bevezetés

Ez a dokumentum leírja hogyan kapcsolódik az internet-alapú "shopping cart" (bevásárló kocsi) rendszer az internet alapú e-gold fizetési rendszerhez. Ez az interfész standard HTML nyelvű formokat használ, hogy egy egyszerű módot biztosítson az online kereskedő számára, hogy integrálódjon az e-gold rendszerbe, azért hogy ezt a fizetési módszert (is) használja áruiért vagy szolgáltatásaiért cserébe. Amint a shopping cart interfész elérte az e-gold Ltd. szerverét, az online vásárlónak lehetősége nyíllik arra, hogy a saját e-gold számlájáról fizessen közvetlenül a kereskedő e-gold számlájára.

Ez a dokumentum minta HTML formokat is kínál interfészül az e-gold fizetési rendszerhez. Ezek a minták egyenértékűek azzal, amikre a kereskedőnek szüksége lenne az ő bevásárló kocsi rendszerének ellenőrző pontján arra, hogy kapcsolódjon az  e-gold fizetési rendszerhez. Végül azok a formok is bemutatásra kerülnek, amiket a kereskedő rendszerének küld vissza a  fizetési rendszer.

1.1             Kinek szól?

Ezt a dokumentumot az online kereskedőt támogató technikai személyzetnek szánjuk. Ezek vagy webmesterek vagy programozók, akiknek megvan az alapvető HTML alkalmazási ismeretük.

1.2             Terminológia

1.3             Az e-gold Shopping Cart Interface áttekintése

1.3.1       Azonosítás

Az e-gold Shopping Cart Interfész (SCI) egy HTML formokon alapuló interfész, amit a kereskedő be tud illeszteni a saját weboldal alapú bevásárló kocsi rendszerébe úgy, hogy lehetővé tegye a vásárlói számára az e-gold-dal  való fizetést. Az SCI támogatja a Secure Sockets Layer (SSL) alapú biztonságos adatcserét.

1.3.2       Célok

1.3.3       Implementáció

Az e-gold Shopping Cart Interfész egy kereskedő webszerverével az 1. ábrán feltüntetett módon áll kapcsolatban. Ez az egyszerűsített ábra megmutatj azt, hogy egy online vásárló hogyan lesz átirányítva a kereskedő normál bevásárló kocsi webszerveréről az e-gold web szerverére, hogy végrehajtson, (vagy megszakítson) a kereskedő részére történő e-gold  kifizetést. Az alapvető sémát magyarázzuk el itt, később jóval részletesebb leírás olvasható még ebben a dokumentumban. Figyelje meg, hogy minden kommunikáció a vásárló web böngészője és az e-gold szerver között biztonságos, hiszen SSL titkosító eljárást használ.
A kereskedőnek módosítania kell jelenlegi bevásárló kocsi rendszerének ellenőrző pontját annak érdekében, hogy ezentúl az e-gold-ot is bevegye a fizetési lehetőségei közé. Ezért ha a vásárló fizetési eszközként az e-gold-ot választja ki az ellenőrző ponton, akkor ő valójában benyújt egy vásárlási információkkal ellátott HTML formot az e-gold web szerverének (1. ábra, 1. lépés). Az e-gold-nak benyújtott formnak tartalmaznia kell a kereskedő e-gold számlaszámát, a vásárlás összegét, stb. Más kereskedő specifikus információt, mint például a rendelési szám, stb. be lehet illeszteni a formba rejtett szövegmezőként.
Az e-gold rendszer ezután egy HTML formátumú felhasználói intefészen keresztül (lásd 1. ábra) lehetőséget nyújt a vásárlónak, hogy a fizetési tranzakciót engedélyezze vagy pedig megszakítsa. Az e-gold rendszer visszaadja a vezérlést a kereskedő bevásárló kocsi rendszerének, egyszerűen a két konfigurálható cél URL link egyikével (az ábrán X és Y weboldalként jelölve), attól függően, hogy a tranzakció sikeres vagy sikertelen volt a vásárló döntésétől függően (1- ábra 2-es vagy 3-as lépés).

Továbbiakban, ha egy sikeres fizetés történt a kereskedő részére, a fizetési információkat közvetlenül az e-gold szervertől el lehet küldeni az alábbi eszközök egyikével a kereskedő beállítása szerint a STATUS_URL bemeneti (input) mezőjében:

Azért, hogy a kereskedő megfelelő támogatást kapjon a kritikus fizetési információ érvényesítésére, az e-gold szerver generál egy MD5 hash értéket a fizetés kritikus adataiból és egy "megosztott titkos"-ból,  ami magában foglal egy 128 bites hash-t a fizetési információk mellett. Különféle szoftver eszközök állnak a kereskedő rendelkezésére, hogy leellenőrizze a megkapott MD5 hash értéket az elvárt MD5 hash értékkel. Ha az MD5 hash értékek megegyeznek, akkor a kereskedő meglehetős biztonságban lehet azzal kapcsolatban, hogy:
a)  a fizetést bizonyító információt az e-gold szerver adta ki,
b)  a fizetési adat úgy érkezett meg, ahogy azt az e-gold szerver elküldte (nem történt az adatokkal manipuláció út közben).

1. ábra: A Shopping Cart Interfész egyszerűsített ábrázolása

(Az ábrán feltüntetett angol szöveg fordítása:
a kereskedő web szervere (szürke rész), azon lefelé: a kereskedő ellenőrző oldala, e-gold (az 1-es nyíl mutat ki belőle); sikertelen vagy nem volt fizetés oldal (2-es nyíl mutat rá); sikeres fizetés oldal (a 3-as nyíl mutat rá);
az e-gold web szervere - www-e-gold.com (világoskék rész), azon balról jobbra; e-fém fizetési form, alatta: előnézet, alatta: törlés; fizetés előnézet oldal, alatta: megerősítés, alatta: törlés; fizetési megerősítési oldal, alatta: folytatás;
a 2-es nyíl kiindulásánál: sikertelen, nincs fizetés;
a 3-as nyíl kezdeténél: sikeres fizetés;
Megjegyzés: Itt nem mutattuk meg, hogy egy form (vagy e-mail) lett-e elküldve az e-gold szerverről a kereskedő szerverére.)

Röviden szólva az 1-es ábra nem teljes, mert nem mutatja be azt, hogy a Shopping Cart Interfész valóban három elemet foglal magában:

1. A kereskedő wen szerverét,
2. az e-gold web szervert,
3. a vásárló web böngészőjét.

2. ábra: Az SCI fülnézeti vázlata

A Shopping Cart Interfész részletes leírása

Ez a rész részletes információt nyújt, hogy lehetővé tegye a kereskedő bevásárló kocsi rendszerének ellenőrző pontján az e-gold fizetési rendszerhez való kapcsolódást.

1.4             Az e-gold fizetési rendszer belépő formjai

A fromaképernyőt a vásárló web böngészője nyújtja be az e-gold web szerverének, és elegendő adatot kell tartalmaznia ahhoz, hogy teljesen leírja az aktuális vásárlást az e-gold fizetési rendszernek. Neek a formnak tartalmaznia kell más rejtett szövegmezőket is, hogy kontrollálja az e-gold szerver és a kereskedő szervere közötti kapcsolatot, ha a fizetés lezajlott vagy megszakadt. Ezt a formot az SCI belépő formjának nevezzük, mert ezen keresztül jut be a vásárló  a kereskedő bevásárló kocsi rendszerét használva az e-gold fizetési rendszerbe. A belépő pont specifikációját ebben a részben adjuk meg.

1.4.1       Az AKCIÓ belépő form

A kereskedőnek az ő AKCIÓ belépő fromját az alábbi linkre kell továbbítania:
"https://www.e-gold.com/sci_asp/payments.asp".
Ez egy biztonságos SSL link az e-gold web szerver Active Server Page-ére mutatva (aktív szerver oldal), amely a bevásárló kocsi interfész (SCI)-en keresztüli fizetéséket kezeli.

1.4.2       A belépő form METHOD beállítása

A kereskedőnek a form METHOD-ját POST-ra kell állítania. Ez a módszer beállítás megengedi az e-gold aktív szerver oldalaknak, hogy megfelelően lekérdezhessék a benyújtott form rejtett szövegmezőinek értékeit.

1.4.3       A rejtett szöveg mezők a belépő formon

A belépő form rejtett szövegmezőiben a vásárló vásásrlásáról és a kereskedő meghatározta információk kerülnek átvitelre. A belépő formnak tartalmaznia kell a kötelező mezőket, de tartalmazhatnak ezeken kívül más opcionális kereskedő specifikus rejtett szövegmezőket is, ahogy azt a későbbiekben elmagyarázzuk.

1.4.3.1     A kötelező és a fromhoz kapcsolódó opcionális rejztett szövegmezők

Az alábbi 1. táblázat sorolja fel a kötelező rejtett szövegmezők neveit és a hozzájuk tartozó értékeket és azok használatát.

A mező neve	A mező értéke és használata
PAYEE_ACCOUNT	A kereskedő e-gold számlaszáma, amire a fizetésnek történnie kell.
PAYEE_NAME	Az a név, amit a kereskedő szeretne megjeleníteni kedvezményezett számlanévként az e-gold fizetési fomaképernyőn. Például: "Kis Pista kereskedése."
PAYMENT_AMOUNT	A vásárlás teljes értéke a fizetési egységben véve (lásd alább). Az értékre példák (vigyázz, tizedespont!):  345.23 és  0.00012. A mennyiség 6 tizedesjegyet tartalmazhat, hogy lehetőség nyíljon nagyon kis mennyiségek fizetésére és a rendkívüli pontosságra.
PAYMENT_UNITS	Ez jelzi a mennyiségi egységet, amit az előbbi PAYMENT_AMOUNT mező értékeként megadtunk. A lehetséges egységet sokféle nemzeti valuta és két tömegegység közül választhatjuk. Lásd a 2-es táblázatot a lehetséges értékek teljes felsorolásához. Megjegyzés: ha a fizetési egység TRÓJAI UNCIA vagy GRAMM, akkor ez kötelezővé teszi, hogy a PAYMENT_METAL_ID nem lehet nulla (0).
PAYMENT_METAL_ID	Annak a  fémnek numerikus kódja, amiben a fizetés megtörténik, ahogy az a 3-as táblázatban adott.
PAYMENT_ID	(Opcionális) Ezt a mezőt a keresekedő felhasználhatja rendelési számnak, számla azonosítónak vagy bármely más hivatkozási jelsorozatnak.  Ez a mező benne lesz az MD5 üzenetben, ami a fizetés nyugtázásakor küld vissza a rendszer. Ha a mező nincs az SCI belépő formban. a "NULL" karaktersorozat lesz felhasználva az MD5 üzenet kiszámításánál. Ez a mező látható és rákereshető az e-gold számlatörténetben, akár a fizető, akár a kedvezményezett oldaláról. Ezt úgy hívjuk, hogy "kereskedői hivatkozás". Akár 50 karakter (betű és/vagy számjegy) hosszú is lehet.
STATUS_URL	(Opcionális) Kontrollálja a fizetési státusz visszaigazolását az e-gold szerver és a  kereskedő szervere között. Nem készül visszaigazolás a kereskedőnek  ha ez a mező nincs jelen vagy ha az értéke "NULL". Más esetben a mező értéke határozza meg hogyan és hová legyen a fizetési státusz elküldve, ahogy az az alább le van írva: Fizetési státusz e-mail-ben: A fizetési státusz egy e-mail formájában lesz elküldve, ha a mező értéke egy "mailto:és egy e-mail cím". Példa ennek megadására: "mailto:kismuki@nagybolt.hu". Megjegyzendő, hogy a "mailto:" csupa kisbetűvel irandó, egyébként a betűváltásnak már nincs jelentősége az e-mail cím megadásánál. Fizetési státus  form, POST módszerrel: A fizetési státuszt egy HTML formban adja meg, ha egy URL lesz meghatározva a  STATUS_URL  mezőben. A form át lesz küldve erre az URL-re POST módszerrel (METHOD) az e-gold szervel által, ha az e-gold fizetés sikeresen megtörtént. Ezért a cél URL egy cgi programra mutat normál esetben, vagy másmilyen feldolgozásra.  Ez az URL lehet biztonségi URL, azaz https. Egy péda a megadására: "https://www.animalware.com/orderpayment.asp" Az egyedüli érvényes URL tipusok "mailto:", "http://", és "https://". Nem standard port számok nem támogatottak.
PAYMENT_URL	Ez az az URL vagy hypertext link, ahová a vásárló böngészője a sikeres e-gold fizetés után a kereskedőhöz visszakerül. Ez a vásárló normális visszatérő útvonala a kereskedő bevásárló kocsi rendszerébe.  Ez az URL lehet biztonsági https protokoll is. Alapértelmezésként az POST műveletű form állomása. Más akciók is lehetségesek, ha az opcionális PAYMENT_URL_METHOD mezőt kitöltötték (lásd alább).
PAYMENT_URL_METHOD	(Opcionális) Ez a mező kontrollálja hogyan legyen a  PAYMENT_URL mező felhasználva. A PAYMENT_URL_METHOD mező értéke lehet "POST" vagy "GET" vagy "LINK", és csupa nagybetűvel kell megadni. Az akciók a következők lesznek: "POST" - A fizetési státusz a PAYMENT _URL-re a HTML form a POST módszerével kerül ki. "GET" -  A fizetési státusz a PAYMENT URL-re  a HTML form a GET módszerrel kerül ki.. "LINK" - Amikor megtörténik a fizetés, egy egyszerű hypertext link lesz felhasználva a PAYMENT_URL-re való visszatérérsre. Ez az opció megengedi a kereskedőnek, aki nem tud cgi-t elhelyezni a web oldala hostján, hogy egy tiszta linket kapjon vissza az ő html oldalú honlapjára, hogy elkerüljük a http 405-ös hibát.
NOPAYMENT_URL	Ez az az URL vagy hypertext link, ahová a vásárló böngészője a sikertelen vagy törölt e-gold fizetés után a kereskedőhöz visszakerül. Ez a vásárló normális visszatérő útvonala a kereskedő bevásárló kocsi rendszerébe, amikor egy e-gold fizetést nem lehetett végrehajtani, vagy törölve lett. Megjegyezzük, hogy ez az URL lehet ugyanaz az URL is, amit a PAYMENT_URL-nél megadtunk, mivel a státusz egy rejtett szövegmezőben is meg van adva, hogy megkülönböztessük a kétféle fizetési végeredmény lehetőséget. Ez az  URL lehet biztonságos https protokoll is. Alapértelmezésként ez az URL POST form műveletként van meghatározva, de más akciók is  lehetnek beállítva az opcionális NOPAYMENT_URL_METHOD mező kitöltésével. (lásd alább).
NOPAYMENT_URL_METHOD	(Opcionális) Ez a mező kontrollálja hogyan legyen a  NOPAYMENT_URL mező felhasználva. A NOPAYMENT_URL_METHOD mező értéke lehet "POST" vagy "GET" vagy "LINK", és csupa nagybetűvel kell megadni. Az akciók a következők lesznek: "POST" - A sikertelen státusz a NOPAYMENT _URL-re a HTML form a POST módszerével kerül ki. "GET" -  A sikertelen státusz a NOPAYMENT URL-re  a HTML form a GET módszerrel kerül ki.. "LINK" - Amikor megtörténik a fizetés, egy egyszerű hypertext link lesz felhasználva a NOPAYMENT_URL-re való visszatérérsre. Ez az opció megengedi a kereskedőnek, aki nem tud cgi-t elhelyezni a web oldala hostján, hogy egy tiszta linket kapjon vissza az ő html oldalú honlapjára, hogy elkerüljük a http 405-ös hibát.
BAGGAGE_FIELDS	Ez a mező szab határt  a rejtett szövegmező neveknek, amit kizárólagosan a kereskedő használ az ő saját céljaira. Egy példa az értékre: "KEY_CODE CUSTOMER_ID BATCH_NUM". Ha a kereskedőnek nincs szüksége további mezőkre, akkor a  BAGGAGE_FIELDS-nek egy üres karakterláncra kell mutatnia  (""). Az összes itt megadható mezőnek és névnek maximum 4000 byte áll a rendelkezésére.
SUGGESTED_MEMO	(Opcionális) Ha ez az input (bemeneti) mező jelen van, akkor az e-fém fizetés MEMO (emlékeztető) területe előre ki van töltve ezzel az értékkel. Legfeljebb 50 karakter lehet a memo mezőben. (A fogyasztó szabadon szerkesztheti a memo mezőt, tehát annak a tartalma nem feltétlenül marad változatlan.)
FORCED_PAYER_ACCOUNT	(Opcionális) Ha ez au input mező jelen van, akkor az a e-gold számlaszám, amiről a kifizetés meg fog történni, fix és nem lehet szerkeszteni/változtatni a vásárló által. Akkor használatos, ha egy bizonyos számlaszámról akarjuk, hogy ki legyen fizetve a kereskedő.A számlaszám 1 és 9 számjegy közötti érték lehet.

1. táblázat: A kötelező és a formhoz kapcsolódó opcionális rejtett szöveg mezők

 

1.4.3.2      Opcionális kereskedő specifikus rejtett szövegmezők

További opcionális rejtett szövegmezőket vehet be a kereskedő a benyújtott formhoz, a kereskedő kedve szerint, mint például rendelési szám, partnerkód, vásárlókód, stb., ezeknek a mezőknek a neveit a  BAGGAGE_FIELDS nevű szövegmezőbe.
Az opcionális mezőnév/érték párokat az e-gold rendszer magával viszi a fizetési processzen keresztül és így végül átadja a kereskedő web oldalának, a változatlan értékeikkel együtt. Ezért, ha a kereskedő úgy kívánja, hogy ezek a rejtett mezők átkerüljenek hozzá, fel kell sorolnia ezeket a mező neveket a  BAGGAGE_FIELDS értékeként.

Más szavakkal, a e-gold rendszer csak olyan kereskedő specifikus rejtett szövegmezőket fogad el, amelyeknek a mezőnevei fel vannak sorolva a BAGGAGE_FIELDS mezőben.

Megjegyzendő, hogy minden a BAGGAGE_FIELDS-ben felsorolt névnek fel kell tűnnie a belépő formon vagy másként ez hibát fog okozni, ha a formot benyújtja az e-gold web szervernek.

Amikor a vásárló ráklikkel az e-gold fizetés gombra a kereskedő bevásárló kosár rendszerében, ez a forma lesz benyújtva (1. ábra: 1-es lépés) az SCI fizetés Aktív Szerver Oldalra az e-gold web szerveren. A cél Aktív Szerver Oldal dinamikusan generál egy aktuélis e-gold e-fém fizetési formot vissza a vásárlóhoz. Ez a fizetési form a következő adatokkal már feltöltve jelenik meg:

a)      Payee - kedvezményezett (a kereskedő neve, ahogy az a PAYEE_NAME mezőben meg lett határozva.)

b)      Payee Account number - a kedvezményezett számlaszáma (ahogy az a PAYEE_ACCOUNT mezőben áll.)

c)      Payment amount - a fizetendő mennyiség (ahogy az a PAYMENT_AMOUNT mezőben áll.)

d)      Payment units - fizetési egység (ahogy az a PAYMENT_UNITS mezőben áll). A fizetési egység bármelyik érték lehet, ami a 2. táblázatban fel van sorolova. Megjegyzés: más támogatott pénznemek is felkerülhetnek a jövőben.

e)      Payment metal - a fizetési fém (ahogy az a PAYMENT_METAL_ID mezőben áll). Ez a fémnév az a fém, amiben a fizetés megtörténik majd. Megjegyzendő, hogy ha ez az érték nulla (0) azt jelenti, hogy a vásárló szabadon választhat a fémek közül. Másként a fizetést csak a meghatározott fémben lehet lebonyolítani. A 3. tábla mutatja a PAYMENT_METAL_ID mező lehetséges értékeit.

 

2. táblázat: A támogatott fizetési egységek

 

3. táblázat: Fizetési fémek

1.5             A vásárló kapcsolódása az e-gold fizetési rendszerhez

Amint a vásárló böngészője benyújtotta a kezdeti formot az  e-gold fizetési rendszernek, a vásárló felhasználó interfésze meglehetősen hasonló lesz a normál e-gold e-fém fizetési eljáráskor látotthoz. Az eljárást alább körvonalazzuk:

1.      Egy e-pénz fizetési utalvány form hasonló ahhoz, ami a 3. ábrán látható. Ez a form megengedi a vásárlónak, hogy opcionális emlékeztetőt írjon be, és beírja a saját e-gold számlaszámát és megadja saját jelszavát, hogy engedélyezze a fizetést. Ha a kereskedő megengedte, hogy fémet is válasszon, akkor egy kis dobozka tűnik fel e célból. Amikor a vásárló kitöltötte a formot, akkor választhat a Preview - előnézet gomb vagy a Cancel - törlés gomb között. A törléssel azonnal megszakítja az eljárást, és az erre az esetre érvényes URL kapja meg a vezérlést. Az erre a célra meghatározott URL lehet egy web oldal, egy cgi program vagy más HTML feldolgozó program (ez lehet egy aktív szerver oldal vagy . Perl script), hogy kezelje a vásárló meghiúsított tranzakcióját a kereskedő bevásárló kocsi ellenőrzési pontjánál.

2.      Ha a vásárló a Preview - előnézet gombra klikkel, a fizetési utalvány form be lett nyújtva az e-gold web szervernek. Amikor az e-gold rendszer megkapja aformot a következő eljárást hajtja végre:

a)      A vásárló számlaszáma és jelszava érvényességét ellenőrzi.

b)      A kedvezményezett számlaszámának az ellenőrzése.

c)      A vásárló e-gold számlaegyenlegének az ellenőrzése, hogy az egyenleg nagysága elegendő-e az adott kifizetés végrehajtására.

3. ábra: Fizetési utalvány mintaform

3.      feltéve, hogy nem történt eddig hiba, az e-gold rendszer a vásárló képernyőjén megjelenteti az előnézeti formot. Ez az oldal a következő információkat jeleníti meg:

a)      a kedvezményezett neve és számlaszáma,

b)      a fizető neve és számlaszáma,

c)      a fizetés összege (kifejezve a PAYMENT_UNITS-ban megadott egységben),

d)      a fizetés féme,

e)      a teljes fém mennyisége (súlya) amit levonnak a fizető e-gold számlájáról ha a tranzakció engedélyezve lesz,

f)        egy gomb a fizetés jóváhagyásához,

g)      egy gomb a fizetés törléséhez.

4.      Ha a vásárló ráklikkel a Confirm - jóváhagyás gombra, a fizetési előnézeti form benyújtásra kerül az e-gold web szerverre. Ennek a formnak a megérkezésekor az e-gold szerver megismétel minden korábbi érvényesítési eljárást, és ha nem talál hibát, végrehajtja a fizetési tranzakciót az e-gold adatbázisban.

5.      Amint a fizetési tranzakció végre lett hajtva, az e-gold szerver opcionálisan elküldi a fizetési tranzakció tranzakció státuszát a kereskedő szerverére a következő módok egyikén:

a)      egy HTML form kerül a kereskedő web oldalán működő form feldolgozó programhoz. A kiválasztott cél URL-t (FORM ACTION) a kereskedő a bevásárló kosár interfészében határozta meg. Az URL-t a STATUS_URL nevű rejtett szövegmezőből veszi a rendszer. A formot a POST módszerrel adja ki a rendszer. Bármiylen válasz, amit a kereskedő rendszere ad, figyelmen kívül marad az e-gold rendszer részéről,

b)     egy e-mail lesz kiküldve a STATUS_URL mezőben megadott e-mail címre.

6.      Ezt követően egy fizetési megerősítési oldal lesz kiküldve a vásárlónak a e-gold rendszerből. Ez az oldal (lásd a 4. ábrát) a következőket tartalmazza:

a)      a fizetés összefoglalását,

b)      az e-gold fizetési tranzakció hivatkozási számát,

c)      egy "Continue - folytatás" feliratú gombot. Erre a gombra klikkelve a vásárló böngészője benyújt egy formot (vagy egyszerűen egy linket) arra at URL-re, amit a PAYMENT_URL mező állít be. Ez a normál vissatérési útvonal a kereskedő rendszerébe.

 

4. ábra: Fizetési megerősítés mintaoldal

d)      Ha a vásárló azt választja, hogy törli (cancel) a fizetési eljárást, akkor azt okozza, hogy benyújt egy formot (vagy egyszerűen egy linket) arra az URL-re, amit a NOPAYMENT_URL mező határoz meg. Ez az alternatív visszatérési útvonal a kereskedő rendszerébe.

e)      Ha az e-gold rendszer hibát talál a fizetési eljárás során, egy megfelelő válasz oldalt ad ki az e-gold rendszer a vásárlónak. Ha ezt a válaszoldalt a vásárló elutasítja, (azzal, hogy a "Return to Merchant - vissza a kereskedőhöz" gombra klikkel), azt okozza, hogy a böngészője benyújt egy formot (vagy csak egy linket) arra atz URL-re, ami a  NOPAYMENT_URL mezőben áll.

2.1             Az e-gold fizetési rendszer kapcsolata a kereskedő rendszeréhez

Az e-gold fizetési rendszer kapcsolatba kerül a kereskedő rendszerével akkor is, ha a fizetés sikeres volt, és akkor is ha sikertelen vagy azért mert a vásárló megszakította, azaz törölte azt, vagy mert a rendszer valamilyen hibát észlelt. Az e-gold fizetési rendszer a következő módon jár el:

a)      amint a fizuetés megtörtént, a vásárló visszakerül a kereskedő oldalára,

b)      ha a fizetés nem történt meg bármilyen ok miatt, a vásárló vissaztér a kereskedő által meghatárott web oldalra.(ismét csak valahová a kereskedő honlapján).

c)      abban az esetben, ha a fizetés megtörtént, egy fizetést megerősítő információt küld a kereskedőnek vagy egy HTML formában a kereskedő szerverére, vagy ilyen egy e-mail-t küld ki a kereskedőnek.

2.1.1       A kereskedő rendszerének elküldött formok

Alapjában véve három különböző féle HTML form van, ami a kereskedő web szerverére lesz benyújtva, és mindegyiknek megvan a saját célja. Ezen formok összefoglalása olvasható a 4. táblázatban.

Új lehetőségek állnak rendelkezésére a kereskedőnek, hogy konfigurálja az ő belépési fromját az SCI-nek, és felülírják ezeket az alapértelmezett SCI akciókat. A most elérhető lehetőségekkel a következőkre lehet rávenni az SCI-t:

a)      használj egyszerű hypertext linkeket formok helyett, hogy visszaadja a kontrollt a kereskedő szerverére, akár történt, akár nem történt fizetés,

b)      küldess e-mailt (form helyett) a fizetés igazolására,

c)      nyomd el a fizetési visszaigazolást egészen, ha úgy kívánja.

A forma neve	Elküldő	URL-hez, általa meghatározva	Mi a célja
Fizetési transakció form	e-gold szerver	STATUS_URL	A fizetési tranzakció megerősítésére ad lehetőséget
Vásárló normál visszatérő form	A vásárló böngészője	PAYMENT_URL	A vásárló normál tranzakciós formja, amit az e-gold fizetési rendszer küld vissza a kereskedő shopping cart rendszerének (ha a fizetés megtörtént).
Vásárló alternatív visszatérő form	A vásárló böngészője	NOPAYMENT_URL	A vásárló alternatív tranzakciós formja, amit az e-gold fizetési rendszer küld vissza a kereskedő shopping cart rendszerének (ha nem történt meg a fizetés).

4. táblázat: A kereskedő rendszerének visszaküldött formok

Egy vásárló az e-gold fizetési eljárásának három féle kimenete lehet:

1.      A fizetés sikeresen lezajlott. Ebben az esetben::

a)      a Payment Transaction Form - Fizetési tranzakciós formot az e-gold szerver minden esetben benyújtja, hogy meggyőződjön arról, hogy a fizetés megtörtént és a rendszer kiadja az ehhez tartozó kötegszámot is.

b)      a Buyer Normal Return Form - Vásárló normál visszatérő formját szokásos módon a vásárló böngészője nyújtja be. A fromba állapot információk vannak beágyazva, amelyek azt mutatják, hogy a fizetés megtörtént, és az  e-gold kiadta a tranzakció kötegszámát.

2.      A fizetést megkísérelték, de az valamilyen ok miatt félresiklott. Ebben az esetben:

a)      a Buyer Alternate Return Form - Vásárló alternatív visszatérő fromját nyújtja be a vásárló böngészője. A formba állapot információk vannak beágyazva, amelyek azt jelzik, hogya fizetés nem lett végrehajtva.

3. A vásrló törölte a fizetési eljárást menet közben. Ebben az esetben:

a)      a Buyer Alternate Return Form - Vásárló alternatív visszatérő fromját nyújtja be a vásárló böngészője. A formba állapot információk vannak beágyazva, amelyek azt jelzik, hogya fizetés nem lett végrehajtva.

Kérem jegyezze meg, hogy csak akkor nyújt be az e-gold szerver egy formot közvetlenül a kereskedő web szerverére, ha a fizetés sikeres volt. Ez a form közvetíti a fizetési tranzakció állapotát az e-gold rendszerből vissza a kereskedő rendszerére rejtett szövegmezőkben.

Ez a form feleslegesnek tűnhet egészen addig, amíg úgy nem gondolja, hogy a vásárló böngészője által közvetített fizetési tranzakciós adatok vissza a kereskedő szerverére megbízhatatlanok lesznek. Miért?

a)      A vásárló lehet, hogy nem követi atz elvárt útvonalat, hogy teljesen befejezze a tranzakciót a kereskedő bevásárló kocsi rendszerébe visszajutva. Lehet, hogy például visszahív egy korábban elmentett HTML linket, és felhasználva azt egy másik weblapra ugrik át.

b)      A várásrló módosítani tudja a HTML formot, és elküldi azt a saját böngészőjének, mielőtt benyújtaná azt a kereskedő rendszerének.

2.1.1.1                        A fizetési tranzakció form

Az 5-ös táblázat mutatja azokat a rejtett szövegmezőket, amelyek mindig jelen vannak a Fizetési tranzakció formban (Payment Transaction Form), amely közvetlenül az e-gold szerverről átküldésre kerül a kereskedő szerverére.

Megjegyzendő, hogy a PAYEE_ACCOUNT mező visszatérő értékének meg kell egyeznie a kereskedő által kiadott SCI belépő formban elhelyezett számlaszámmal, mivel lehet, hogy a vásárló képes volt matatni a PAYEE_ACCOUNT mező értékével, mielőtt azt benyújtotta az e-gold szervernek. Ezért a kereskedő bölcsen teszi, ha leellenőrzi ezt a mezőt, biztosítva azt, hogy az e-gold fizetés valóban megtörtént az elvárt számlaszámra.

Ebbe a formba be is foglalhat rejtett szöveg mező és érték párokat (ha vannak), amit előzőleg a BAGGAGE_FIELDS mező ben meghatározott.

Ezt a formot a POST módszerrel (method) fogja benyújtani az e-gold rendszer a kereskedő szerverére, a korábban már leírt URL-re, a STATUS_URL mezőben megadottak szerint. Ez az URL tipikusan egy cgi program ami elolvassa a form rejtett nezőit és annak megfelelően teszi a dolgát. és nagyon is valószínű, hogy a program eltárolja a rendelési információkat és az e-gold tranzaakciós információkat elszámolási célokra.

Semmilyen választ nem várnak el a kereskedő rendszerétől, ha ezt a formot benyújtották, és amit esetleg válaszolna a kereskedő rendszere, azt egyszerűen figyelmen kívül hagyja az e-gold szerver. Megjegyzendő, hogy az e-gold szerver rész úgy van megtervezve, hogy újra benyújtja a Payment Transaction Formot egészen addig, amíg egy érvényes http(s) státus választ kap jelezve egy sikeres postot) vagy amíg a beállított újrapróbálkozás ki nem merül. Ezért bizonyos kommunikációs hiba állapot fenállásakor lehetséges a kereskedő render részéről, hogy dupla Payment Transaction Formot kap.

5. táblázat: Azon rejtett szövegmezők, melyek mindig jelen vannak a fizetési trazakciós formon
(Payment Transaction Form)

2.1.1.1.1                    Az MD5 Hash érték

A kereskedő szerverére benyújtott fizetési form egy "V2_HASH" nevű rejtett szövegmezőt is tartlamz. Ennek a mezőnek az értéke egy 128 bites szövegkivonat, 32 nagybetűs hedadecimális jegyet tartalmazó karakterláncként megjelenítve. A V2_HASH egy több mező összekapcsolásából megszületett MD5 számítás alapján előállított karakterlánc, amely a  STATUS_URL-ben megadott helyre továbbítódik. Az összekapcsolt mezők alább láthatók egy ":" határolójellel elválasztva egymástól:

PAYMENT_ID:PAYEE_ACCOUNT:PAYMENT_AMOUNT:PAYMENT_UNITS:PAYMENT_METAL_ID:
PAYMENT_BATCH_NUM:PAYER_ACCOUNT:AlternateMerchantPassphraseHash:
ACTUAL_PAYMENT_OUNCES:USD_PER_OUNCE:FEEWEIGHT:TIMESTAMPGMT

(megjegyzés: megjelenítési okokból van csak a mezősor három sorosra feltördelve. Valójában ez egyetlen hosszú mezőláncsor.)

Fontos: Ha egy PAYMENT_ID mező korábban nincs a kereskedő részéről rendelkezésre bocsájtva, a "NULL" karakter- sorozat lesz használva értékként a fenti láncban.

Egy kereskedő ellenőrizni tudja a kapott adatok érvényességt azzal, hogy összehasonlítja a saját, ugyanazon mezőkön elvégzett  MD5 kiszámított értékét a kapott értékkel. Ha a kereskedő által kiszámított MD5 érték megegyezik a V2_HASH mező értékével, akkor meglehetős biztonsággal azt mondhatja, hogy a kapott fizetési adat érvényes.Egy egyszerű MD5 ellenőrző oldal elérhető a https://www.e-gold.com/acct/md5check.html oldalon.

Példa a V2_HASH-re

Tegyük fel, hogy a kereskedő által használt belépő fomban az 123456 számú e-gold fizetésnél a PAYMENT_ID = AB-123
Az alternatív jelszava pedig: "ohboyi msogood1".
Ez a kereskedő kap egy 300 USA $ értékű aranybani befizetést az e-gold bevásárló kocsi interfészen keresztül a 456789 számú e-gold számláról. Az e-gold rendszertől visszakapott értékek az ő STATUS_URL-jében megadott módon megkapva:

PAYMENT_ID = AB-123
PAYEE_ACCOUNT = 123456
PAYMENT_AMOUNT = 300.00
PAYMENT_UNITS = 1
PAYMENT_METAL_ID = 1
PAYMENT_BATCH_NUM = 789012
PAYER_ACCOUNT = 456789
ACTUAL_PAYMENT_OUNCES = 2.000000
USD_PER_OUNCE = 600.00
FEEWEIGHT = 0.000833
TIMESTAMPGMT = 876543210

Először mi kiszámítjuk a kereskedő alternatív jelszavához tartozó MD5 hash értéket, ami:
67C305DCE49D430D540FCB3D6D2E13B0
Most mi felépíthetjuk a saját konkatenált (összeillesztett) mezőtarlamainkat, hogy kiszámoljuk a hozzá tartozó hash értéket, amit összehasonlítunk az e-gold-tól megkapott V2_HASH mező értékével. Az összeillesztett karaktersorozat a következő:

AB-123:123456:300.00:1:1:789012:456789:67C305DCE49D430D540FCB3D6D2E13B0:2.000000:600.00:0.000833:876543210

Amikor végrehajtjuk ezen az MD5 hash számolást, akkor a következőt kapjuk:
7F8FAF7DB12315BC2B4B06E163F78D31
És ez lesz a megérkezett V2_HASH mező értékének az elvárt megfelelője.

Egy korábbi verziójú hash mező szintén elérhető a "régebbi" felé való kompatibilitás miatt. Nem ajánlott ennek a használata; használja a V2_HASH mezőt ahelyett.

Régi hash információ:

A  "HANDSHAKE_HASH" nevű rejtett szövegmező szintén rézse a kereskedő szerverére eljutatott formnak.Ez a mezőérték is egy 128 bites üzenet kivonat, ami 32 hexadecimális nagybetűs számjegyből áll. Ez a 128-bites hash érték a következő összekapcsolt mezők MD5 üzenet kivonatának felel meg::

a)       PAYMENT_ID

b)       PAYEE_ACCOUNT

c)       PAYMENT_AMOUNT

d)       PAYMENT_UNITS

e)       PAYMENT_METAL_ID

f)        PAYMENT_BATCH_NUM

g)       PAYER_ACCOUNT

h)      MD5 a fizető e.gold vészhelyzet jelszavának a hash értéke.

2.1.1.2                        A vásárló normál visszaérkező formja

A 6-os táblázat mutatja azokat a rejtett szövegmezőket, amiket a Vásárló normál visszatérő formjában mindig jelen vannak. Ezt a vásárló web böngészője küldi el a kereskedő rendszerének.

Azok a mező és értékpárok is benne lehetnek ebben a formban, amiket a korábban specifikált BAGGAGE_FIELDS mezőben leírtuk.

Ez a form a POST módszerrel lesz eljuttatva arra az URL-re, amit korábban az e-gold rendszernek a PAYMENT_URL nevű mezőben megadtak. Ez az URL tipikus módon egy cgi program, ami elolvassa egy form rejtett mezőinek tartalmát és az olvasottak alapján működve előállít egy weboldalt, amely megengedi a vásárlónak, hogy fejezze be az ellenőrzési ponton az eljárást (mivel a fizetés megtörtént).

6. táblázat: Azon rejtett szövegmezők, melyek mindig jelen vannak a vásárló normál visszetérő formon

2.1.1.3                        A vásárló alternatív visszaérkező formja

A 7-es táblázat mutatja azokat a rejtett szövegmezőket, amelyek mindig rajta vanna a Vásárló alternatív viszzatérő formján, amit a vásárló böngészője küld a kereskedő web szerverének.Továbbiakban bizonyos esetekben a vásárló e-gold számlaszáma is jelen lehet egy rejtett szövegmezőben.

Azok a mező és értékpárok is benne lehetnek ebben a formban, amiket a korábban specifikált BAGGAGE_FIELDS mezőben leírtuk.

Ez a form a POST módszerrel lesz eljuttatva arra az URL-re, amit korábban az e-gold rendszernek a NOPAYMENT_URL nevű mezőben megadtak. Ez az URL tipikus módon egy cgi program, ami elolvassa egy form rejtett mezőinek tartalmát és az olvasottak alapján működve előállít egy weboldalt, amely azt engedi meg a vásárlónak, hogy egy másik fizetési formát válasszon az e-gold helyett, hogy így folytassa tovább az ellenőrzési ponton az eljárást (mivel az e-gold fizetés nem történt meg).

7. táblázat: Azon rejtett szövegmezők, melyek mindig jelen vannak a vásárló alternatív visszetérő formon

Minta formok

Ez a rész számos formot tartalmaz mintaként, amit egy kitalált vásárló, James Bond a High-Tech Widgets-től való vásárlásakor használhatnánk:

a)      egy Belépő HTML formot, hogy illusztrálja az e-gold fizetési rendszerhez való kapcsolódást,

b)      egy Vásárlási tranzakciós formot, olyat, amit az e-gold szerver küldene ki a kereskedő szerverének, amikor a fizetés megtörtént,

c)      egy Vásárló normál visszatérő formot, amit a vásárló web böngészője küldene el a kereskedő szerverének, amikro ez az  e-gold fizetés megtörtént,

d)      egy Vásárlói alternatív visszatérő formot, amit a vásárló web böngészője küldene el a kereskedő szerverére, amikor az e-gold fizetés nem történt meg akármilyen okból kifolyólag.

2.2             Az  e-gold fizetési rendszerbe belépő mintaform

Az 5-ös ábrán látható form egy példa arra a kereskedői ellenőrző oldalra, amoh a vásárló kiválasztja a fizetési formát. Az oldal több különálló formból áll, a különféle fizetési lehetőségeknek megfelelően. A világosság és áttekinthetőség kedvéért a Visa kártya vagy a Discover kártya részek csak töredékesek és az e-gold kiválasztása (vastagbetűsen szedve) teljes és az lenne elfogadva az e-gold SCI rendszer által. A következő megjegyzéseink vannak még a példához:

a)      A vásárlás ellenértéke 109,99 USA dollár értékű arany. A kereskedő csak aza arnyban való fizetést tette lehetővé, mivel a PAYMENT_METAL_ID mező értéke kifejezetten 1 (arany).

b)     A kereskedő két darab "baggage fields"-et (további opcionális mezőket) használ, hogy kezelni tudja a megrendelés állapotát. Ezeket a  BAGGAGE_FIELDS mezőben határozza meg:

egy rendelési számot (ORDER_NUM) a 9801121 értékkel és egy

ügyfél számot (CUST_NUM) a 2067609 értékkel.

További megjegyzés: a mintaformok angol szövegei nincsenek lefordítva a keretekben.

5. ábra: HTML belépési mintaform

a)   Ha fizetés sikeresen megtörtént, a tranzakciós válasz form a következő URL-re kerül benyújtásra: https://www.high-tech.com/cgi-bin/xact.exe

b)     Ha fizetés sikeresen megtörtént, a vásárló böngészője egy HTML formot a következő URL-re küld: https://www.high-tech.com/cgi-bin/chkout1.exe

c)   Ha fizetés nem történt meg sikeresen vagy közben törölték, a vásárló böngészője egy HTML formot a következő URL-re küld:
https://www.high-tech.com/cgi-bin/chkout2.exe

2.3             Fizetési tranzakció mintaform

A 6-os ábra mutatja meg, hogyan nézhet ki a Vásárlási tranzakciós form (Payment Transaction Form) a mi kitalált James Bond-féle vásárláskor. Ez e-gold rendszer a formot közvetlenül a High Tech Widgets szerverére nyújtaná be Mr. Bond sikeres e-gold tranzakciójának igazolásául. A PAYMENT_BATCH_NUM mező értéke ugyanaz az igazolási szám, amit Mr. Bond látna az e-gold fizetési előnézet oldalon, ahol megerősíti a fizetés tényét.

6. ábra: Fizetési tranzakció mintaform

2.4             Vásárló normál visszatérő mintaform

A 7-es ábrán látható példa egy Vásárlói normál visszatérő form lenne, ami a kitalált James Bond-féle vásárláson alapszik. Ezt a formot küldené el Mr. Bond böngészője a kereskedő szerverére, amikor sikeresen befejezte az e-gold fizetési eljárást. Megjegyzendő, hogy ez a form látszólag ugyanazokat az információkat tartalmazza, mint a fentebb látott Payment Transaction Form (Vásárlói tranzakció form), attól eltekintve, hogy e kettő különböző URL-ekre van kiküldve és az normál visszatérő formot arra használjuk, hogy Mr. Bond böngészőjét a kereskedő bevásárló kocsi rendszerébe küldjük vissza, hogy ott befejezze az ellenőrző pontbani eljárást.

7. ábra: Vásárló normál visszatérő mintaform

2.5             Vásárló alternatív visszatérő mintaform

A 8-as ábra egy Vásárlói alternatív visszatérő formra példa, ami a kitalált James Bond-féle vásárláson alapszik. Ezt a formot Mr. Bond böngészője küldené el a kereskedő szerverére, ha az e-gold fizetési eljárás bármilyen ok miatt meghiúsulna. Megjegyzendő, hogy ez a form majdnem ugyanazokat az információkat tartalmazza mint a fenti Vásárló normál visszatérő form, attól eltekintve, hogy itt a PAYMENT_BATCH_NUM mező értéke: 0, ami azt jelzi, hogy fizetés nem történt. Az is megjegyzendő, hogy ez a form egy másik URL-re van elküldve, hogy Mr. Bond böngészőjét a kereskedő bevásárló kocsi rendszerébe arra, az oldalra vigye vissza, ahol egy másik fizetési módot választhat Mr. Bond. Végezetül megjegyzendő, hogy a vásárló e-gold számlaszáma nincs a formban. Ez a helyzet akkor lehetséges, ha a fizetési eljárás még azelőtt véget ért, mielőtt a vásárló beírta volna az ő e-gold számlaszámát.

8. ábra: Vásárló alternatív visszetérő mintaform

Az Ön e-gold Shopping Cart Interfészének a tesztje

2.6             Az Ön SC Interfészének tesztelési módszereinek kezdőbeállítása

Az Ön implementációjának a tesztelésére az ajánlott módszer az, hogy nagyon kicsi vásárló mennyiséggel (például 0,01 USD egyenértékkel) teszteli az SCI rendszerét. Ön fizethet ugyanarra a számlára ugyanarról a számláról. Ez megengedi Önnek, hogy kipróbálja az SCI működőképességét, összekapcsolódását az élő e-gold oldallal. Az éles alkalmazás előtt a rögzített  PAYMENT_AMOUNT mezőt fel kell szabadítania, hogy a valódi érték kerülhessen bele a belépési formba.

Különleges tesztigény vagy tanács esetén, kérjük vegye fel a kapcsolatot az e-gold-dal, felhasználva a honlapon található kapcsolati lehetőséget (Contact us). A weboldal helye: http://www.e-gold.com.

2.7             Implementációs irányvonalak

Itt van néhány általános irányvonal, hogy segítse Önnek a megfelelő SCI interfész módszer kiválasztását:

a)   Egyszerű eladók és azok akik adományokat fogadnak el, amely nem igényel fizetési visszaigazolást vagy nem akarnak e-mail feljegyzést a fizetésről - hagyják ki a STATUS_URL bemeneti mezőt, és állítsák be a PAYMENT_URL_METHOD mezőt és a NOPAYMENT_URL_METHOD mezőt: "LINK"-re. Ez vissza fogja vinni a vsárálót az Ön weboldalára (ahol nincs cgi program).

b)  Azok az eladók, aki le akarják ellenőrizni a fizetést, de nem helyeznek el cgi programot a saját web szerverükre, használják a STATUS_URL mező beállítását egy e-mail URL-re (pl. "mailto:xxx@yyy.net"). Ez az e-mail az e-gold szerverről érkezik, ha az SCI fizetés megtörtént és tartalmazza a fizetési információkat és egy üzenet kivonatot, amit fel lehet használni a fizetés ellenőrzésére tetszés szerint.

c) Azok az eladók, akik mindent akarnak, használják úgy a STATUS_URL a fent leírtak szerint, hogy átadják a visszakapott adatokat egy cgi/asp alkalmazásnak a honlapukon egy https protokolon kresztül. A visszakapott mezők feldolgozásával ellenőrizni tuudják az e-gold fizetést. További ellenőrzést még az MD5 használata jelethet, az üzenet kivonattal a V2_HASH mezőben. Ellenőrizzék, le, hogy az elért weboldal valóban a www.e-gold.com.Ezt meg lehet tenni, ha megnézik a benyújtott IP címet és leellenőrzik, hogy az a 63.240.230.x.

2.8             Biztonsági irányvonalak

Itt van néhány biztonsági irányvonal, hogy segítsen egy biztonságos e-gold SCI implementációt megvalósítani, ami ellenáll rosszindulatú támadásoknak is:

a)   Generáljon egy saját PAYMENT_ID az Ön kereskedői oldalán belül minden egyes potenciálisan megkapandó fizetés előtt. Adja át ezt az e-gold-nak a PAYMENT_ID input mezőben. Tartsa meg a nyomát minden ilyen potenciális fizetésnek az Ön adatbázisában/állományában a kereskedői honlapon.  Tárolja el a várt mennyiséget a PAYMENT_ID-vel együtt és egy jelzéssel, hogy az a fizetés megtörént-e vagy sem.

b) Az e-gold-tól a STATUS_URL-re való fizetési megjegyzés megkapásakor, ellenőrizze le azt a bizonyos PAYMENT_ID-ét, amit megjegyzett a potenciális fizetések listájában. Ellenőrizze le, hogy nem fizették-e ki korábban. (Ez megelőzi az újrafizető típusútámadásokat). Ellenőrizze le, hogy a várt mennyiség érkezett-e meg, és az e-gold számlaszám, amire fizettek, az helyes-e. (Ez megakadályozza az Ön HTML form értékeinek a módosítását.) Ellenőrizze le, hogy a V2_HASH érték helyes. Ha minden ellenőrzés rendben találtatott, módosítsa le a potenciális fizuetések adatbázisát/állományát, hogy azt a PAYMENT_ID-t kifizették.

c)      Bizonyosodjon meg arról, hogy az Ön alternatív kereskedői jelszava hosszú és összetett.

d)   Vizsgáljon ki bármilyen gyanús jelzést, ami az Ön STATUS_URL-jére érkezik. Egy ilyen gyanús jelzés lehet egy form postja, ha nem ment át az iménti b) pontban leírt vizsgán.

e)   Használja a TIMESTAMPGMT mezőt, hogy leellenőrizze annak a tartalmát, hogy értelmes-e. A jövőből érkező jelzés nem értelmes. A távoli múltból érkezett sem az.   

Copyright 2005. magyarEarany All rights reserved - Minden jog fenntartva.  Az e-gold, Better Money TM, e-metal bejegyzett védjegyek az e-gold Ltd. a Nevis Corporation tulajdonában vannak. Használatuk engedéllyel történik.