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: archive@jab.org To unsubscribe send a blank email to [EMAIL PROTECTED]