|
|
Posted by M on 11/11/02 11:31
Ben Ramsey wrote:
>> B is a secure page, with a CC info form that when submitted will
>> process their card, charging the amount of money passed in the
>> encrypted packet, and if the charge succeeds, redirecting back to A. A
>> would probably need to send an order number to B, and B could pass
>> that back to A upon success or failure.
>>
>> All of this is to get around the Apache limitation of allowing only
>> one virtual host to use SSL.
apache does not have this limit. this is limit of https protocol,
because encryption takes place before any request is made, so the only
way to know what SSL certificate to use is the IP address. You can get
apache to listen on more than one IP and use as many certificates as you
like.
>>
>> Anyhow, B could keep track of all of the order numbers it was sent by
>> A, and if it was re-sent a duplicate could simply deny the whole
>> transaction. Thus, if someone sniffed my encrypted "data burrito", and
>> attempted to re-use it to gain access to B, they would fail, since B
>> will only allow that burrito ONCE. Perhaps these order numbers could
>> be GUID's.
You can look at how payment gateways do this. There are basicly 2 ways:
1. postback - when user is redirected from B to A with the result status
and order id, A asks B (rpc, simple get method, anything...) if the
result is really what it got from the user. Check every important
information - order id, amount
2. signing - site B computes a sign from important information of the
transaction (at least order id and amount) and a secret key, and adds
this sign to the redirect url that leads to site A. Site A can then
compute the sign from the same values and check it against sign received
from the server.
In both cases you should also incorporate site id, so site A is not the
only one that can use the interface of site B.
Navigation:
[Reply to this message]
|