I don’t know your server structure and server side code but it is fairly easy (implement 1 day - test a week) to enable everyone to buy and sell premium codes by something like this:
I assume a table t_premCert containing a row for each premium certificate.
This t_premCert table needs four new fields:
1) Sold: ALTER TABLE t_premCert ADD COLUMN sold DATETIME
2) transactionID: ALTER TABLE t_premCert ADD COLUMN transactionID varchar(16) or whatever size the transactionid will have –I would suggest a guid instead of an
autoincrease value to avoid problems with clever hackers abusing a predictable number
3) seller_id_ref_avatar: ALTER TABLE t_premCert ADD COLUMN seller_id_ref_avatar whateever type the avatar id is
4) price: ALTER TABLE t_premCert ADD COLUMN price integer
It would need two masks one for buyer and ond for seller
Process is as follows:
1) Seller presses the new button “Sell premium code” on the user details mask of the buyer.
2) He puts in the code he wants to sell and the price and sends the request to the server.
3) The server checks if code is a) valid and b) the new “sold” (type datetime) column is not higher then NOW() like (select * from t_premCert where sold < now() and cert_id=’whatever’ )
4) The server flags the new “sold” (type datetime) column of the “t_premCert” (however it is called) table of the database with now+ 10 minutes (like: update t_premCert set sold= NOW() + INTERVAL 1 MINUTE, transactionID = ‘>new generated guid<’, seller_id_ref_avatar=id_seller, price=senden_price_from_seller where sold < now() and cert_id=’whatever’). This makes sure no one can use or sell this code the next minute – and sends a buy request with the transaction id, price and duration (3,6 or 12 months) of the prem code to the client.
5) The client has now 30 second to accept the offer (he will see a popup 3,6 or 12 months and price) . If he does deny the offer the sold column will be reverted to null or mindate(like: set sold=DATE('1000-01-01') ).
6) If he goes offline the seller can go on and sell the code to someone else after a minute
7) But - if the buyer accept the offer the server gets notified with the buyers avatar id and the transaction id. If the buyer has the funds the server will be decreased the byers and increase the seller_id_ref_avatar cash amount by the price field content. The original code will be set to sold max date (like: set sold=DATE('9999-12-31')) and a NEW ROW WITH A NEW PERMIUM CERTIFICATE NUMBER will be generated which the buyer will get by private message and in his email.
Done: No code can be sold twice or activated after it has been sold (new colum "sold" needs to check on activation) … the buyer will know the bought code will work 100% and be as secret as a regular bought code … AND EVERYONE who wants a apartment or whatever can now buy a real code and sell it to someone ingame for ingame dollars …
I assume a table t_premCert containing a row for each premium certificate.
This t_premCert table needs four new fields:
1) Sold: ALTER TABLE t_premCert ADD COLUMN sold DATETIME
2) transactionID: ALTER TABLE t_premCert ADD COLUMN transactionID varchar(16) or whatever size the transactionid will have –I would suggest a guid instead of an
autoincrease value to avoid problems with clever hackers abusing a predictable number
3) seller_id_ref_avatar: ALTER TABLE t_premCert ADD COLUMN seller_id_ref_avatar whateever type the avatar id is
4) price: ALTER TABLE t_premCert ADD COLUMN price integer
It would need two masks one for buyer and ond for seller
Process is as follows:
1) Seller presses the new button “Sell premium code” on the user details mask of the buyer.
2) He puts in the code he wants to sell and the price and sends the request to the server.
3) The server checks if code is a) valid and b) the new “sold” (type datetime) column is not higher then NOW() like (select * from t_premCert where sold < now() and cert_id=’whatever’ )
4) The server flags the new “sold” (type datetime) column of the “t_premCert” (however it is called) table of the database with now+ 10 minutes (like: update t_premCert set sold= NOW() + INTERVAL 1 MINUTE, transactionID = ‘>new generated guid<’, seller_id_ref_avatar=id_seller, price=senden_price_from_seller where sold < now() and cert_id=’whatever’). This makes sure no one can use or sell this code the next minute – and sends a buy request with the transaction id, price and duration (3,6 or 12 months) of the prem code to the client.
5) The client has now 30 second to accept the offer (he will see a popup 3,6 or 12 months and price) . If he does deny the offer the sold column will be reverted to null or mindate(like: set sold=DATE('1000-01-01') ).
6) If he goes offline the seller can go on and sell the code to someone else after a minute
7) But - if the buyer accept the offer the server gets notified with the buyers avatar id and the transaction id. If the buyer has the funds the server will be decreased the byers and increase the seller_id_ref_avatar cash amount by the price field content. The original code will be set to sold max date (like: set sold=DATE('9999-12-31')) and a NEW ROW WITH A NEW PERMIUM CERTIFICATE NUMBER will be generated which the buyer will get by private message and in his email.
Done: No code can be sold twice or activated after it has been sold (new colum "sold" needs to check on activation) … the buyer will know the bought code will work 100% and be as secret as a regular bought code … AND EVERYONE who wants a apartment or whatever can now buy a real code and sell it to someone ingame for ingame dollars …