Re: Paypal and "going root"
От | PFC |
---|---|
Тема | Re: Paypal and "going root" |
Дата | |
Msg-id | op.tsg9mcc9cigqcu@apollo13 обсуждение исходный текст |
Ответ на | Re: Paypal and "going root" (Dave Page <dpage@postgresql.org>) |
Список | pgsql-general |
>> Has anybody pondered this and come up with anything? Well, I've done e-commerce stuff although it was with banks, not paypal. There are a few levels of safety : - Level 0 : Total stupidity (osCommerce) Bank redirects to your site. Order is marked as paid with "paid=1" in the URL. Solution : fire the programmer - Level 1 : callback Bank hits URL on your site with data you provided (order_id) so you may mark the order as paid. Technical documentation says to verify the transaction by checking the bank server's IP address. Solution : choose another bank - Level 3 : crypto Bank hits URL on your site with data you provided (order_id) so you may mark the order as paid. Bank encrypts everything and securely signs the data (HMAC, certificate...) This works well. Additionally, you can hit a URL on the bank to check validity. However, if this is not encrypted (SSL...) can you be sure who you are talking to ? My advice is to store, in your table, the signed and encrypted data the bank sends you. Suppose a hacker breaks your verification code and marks his order as paid in the database. Even so, he will never be able to use the bank's certificate to generate a fake signed payment confirmation to insert in your log table. And, usually, the data the bank signs includes the user name, id, order id, amount, and user-specified fields, that you use to store a SHA1 hash of the list of things the user ordered, so he can't steal the payment confirmation from another user, or from a past order. So, if later you suspect something, you can re-check the signatures on the payment confirmation data, and the fraud will be apparent.
В списке pgsql-general по дате отправления: