I am a java guy, so I can show you a bit of what I do.
Below is a code snippet from my process servlet.
// v2_hash info:
// 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
String v2_verify = payment_id + ":" + payee_account + ":" +
payment_amt + ":" + payment_units + ":" +
payment_metal_id + ":" + payment_batch_num + ":" +
payer_account + ":" + ALTPASS + ":" +
actual_payment_ounces + ":" + usd_per_ounce + ":" +
feeweight + ":" + timestampgmt;
try
{
md = MessageDigest.getInstance("MD5");
md.update(v2_verify.getBytes());
v2_verifyHash = StringUtils.toHex(md.digest());
}
catch( NoSuchAlgorithmException nsa )
All of the fields EXCEPT the AlternateMerchantPassphraseHash are
returned by E-Gold. I create the hash of my alternate passphrase. All
of those fields are combined as one string with a ":" seperating each
value. A hash is created of that string.
The value returned by E-Gold as V2_HASH should equal the v2_verifyHash I
created above. If it did not then you have something wrong and need to
investigate.
The things I check for in the return values are the payee_account and of
course the hash comarisons.
There is also a baggage field containing a transaction ID. I mark the
transaction as paid with the status_url return. The transaction is
created when I generate the payment form.
Some folks might be inclined to create the transaction with the
status_url, but you are open to someone hijacking it and just submitting
it multiple times from their own server.
---
You are currently subscribed to e-gold-tech as: [email protected]
To unsubscribe send a blank email to [EMAIL PROTECTED]
