Php form entry/ecommerce ability. Partial functionality for Daily Deal site

Hi, I need a form page for those that click on 'Buy' for a daily deal on my not-yet-live site. This will include ability to accept payments (e-commerce), but not a shopping cart. The form page will follow the Groupon format. If you go to [url removed, login to view], find a deal, and click on 'Buy', you'll see nearly the sum total of this project. I want the entire functionality of the page that allows the user to buy a deal (not SEE the deal, but BUY the deal). My main objectives here are twofold: 1. Have an expert program for form entry using 'best practices', so that I can duplicate the approach with my other form pages on the site. I want to be sure that bad form entries, or ones with odd characters are handled in a way that doesn't cause problems. 2. Have an expert set up the ecommerce capability, including the ability to handle refunds. I don't want to risk doing this wrong myself. The programming will be in PHP with a bit of javascript. You can of course let me know if any of these are not doable. Note, what this is not: *It is not a routine to create the daily deal, or to list it. I have programmed that part. You will be using that for INPUT for your routine. *It is not a routine to update user records for the deal they have chosen. I am programming that part using the OUTPUT of your routine. Please see Advanced Summary for full details. Thanks! Ted

## Deliverables

Hi, I need a form page for those that click on 'Buy' for a daily deal on my not-yet-live site. This will include ability to accept payments (e-commerce), but not a shopping cart. The form page will follow the Groupon format. If you go to [url removed, login to view], find a deal, and click on 'Buy', you'll see nearly the sum total of this project. I want the entire functionality of the page that allows the user to buy a deal. The other piece My main objectives here are twofold: 1. Have an expert program for form entry using 'best practices', so that I can duplicate the approach with my other form pages on the site. I want to be sure that bad form entries, or ones with odd characters are handled in a way that doesn't cause problems. 2. Have an expert set up the ecommerce capability, including the ability to handle refunds. I don't want to risk doing this wrong myself. The programming will be in PHP with a bit of javascript. You can of course let me know if any of these are not doable. Note, what this is not: *It is not a routine to create the daily deal, or to list it. I have programmed that part. You will be using that for INPUT for your routine. *It is not a routine to update user records for the deal they have chosen. I am programming that part using the OUTPUT of your routine. What it IS: *It should have the look and feel of the Groupon 'Buy' page mentioned above: Your Purchase--quantity, price, gift popup info Select Payment Personal Info (to create a login account if not one existing, or fill in if already logged in) Sign-in popup if already has an account and not logged in Billing Info (to send to payment processor--NOTE: I will NOT be retaining credit card numbers. I will retain all other related entries, but not the numbers) Fill in if logged in, allow for editing, create ccard table record if creating Terms of Service *The program will need to check to see if the deal is still on immediately, and inform them if it has closed. It can close either when a max number of purchases is reached or the time has expired (input items from my routine). *All entry fields will need to be checked for proper entry. This probably goes without saying. Are you going to use PHP filters to do this? I have a number of entry pages and they use some validation checks and then htmlentities to put into the database, but I'm unsure if that is the safe/proper way to handle form entry. I'd like to use your logic as a guide for me to go back and correct/enhance my other form pages, so I would like you to program this in the way that is considered 'best practice'. *All appropriate fields on the page will be pre-filled if the user is alreayd logged in, or filled if they log in when they get to the page. Otherwise it is a new user and the fields will need to be completed. *Ability to edit all fields. *I will store credit card related fields for each card in a dbase table but I will NOT be storing store credit card numbers, in order to avoid liability if a hacker were to get in to my database. I use MYSQL. *If there user doesn't already have an account, the program creates a user account with the personal information, and a separate table and with credit billing info. I assume the credit billing info is a separate table since the user can have more than one credit card. User accounts will be created even if when he confirms his entry the deal has closed. The accounts I assume will be created by you would be 1. a basic user account with email, password, name, and 2. table for all credit card info--all the entered info per card with the exception of the cc number, which ties by user, and 3. a gifts table, which contains name, email(if provided) for the those the user gives the deal vouchers to as a gift. *There is a popup for the gifts--to allow the user to write a message. The user clicks on printing one(a voucher) himself for the gift recepient, or enteres the email. These entries need to be stored. *The program allows a person to log in if they aren't currently logged in but already have an account. *For new users, the prog will need to check to see the password is valid and not already being used. Also, the email address. *The program will need to check once again as soon as the person clicks on Complete Order at the bottom to see if the deal is still on or has closed due to a max number of purchases reached or time has expired. If the deal is not on, it needs to inform them and then not try to process the payment. *If the deal is on, the prog needs to process the payment and then when it returns I will need to pick it up from there: I'll need all the input variables (stored in session or still in POST?) in order to create a new account record. I'll also need a confirm/notconfirm and payment amt confirmed back from the processor. From there I'll update the appropriate tables related to the deal and to that user, as well as other users that came before him if the deal has just been 'tipped' for the first time. But again, I will take it from this point. *I assume the Payment Processor will send an email confirming purchase or denial of purchase. *I assume the Payment Processor will allow a way to run tests/dummy payments. 2. PAYMENT REFUND ROUTINE *I'll need a separate routine to refund money to all who have paid for a deal if the deal has expired and the tipping point (min number of purchases) is not reached. *And, also a routine (maybe the same one as above) to allow me to input a user email address in order for the user to be refunded. Both of these will obviously will have to use the Payment Processor to reverse the prior transaction. I can set you up to use my computer via a Plesh interface. I can't think of anything else. I'm looking forward to working with you. Ted

Kĩ thuật JavaScript Microsoft MySQL PHP Quản lí dự án Kiến trúc phần mềm Kiểm tra phần mềm Web Hosting Quản lý website Thử nghiệm trang web Màn hình Windows

ID dự án: #3325366

Về dự án