That will be a little hard do explain, but let me try:
I'm building an online store using Laravel 4 and now I have to create the payment methods and they might be completely different from each other and for each one of them I'll have to build a different number of pages (views), wich could be, as examples:
Credit Card
Get the credit card data (to, first, create a token).
Nice! It was accepted by the company and your token was created, would you really like to pay?
It was paid, thanks!
Credit Card
Get the debit card data.
It was paid, thanks!
Paypal
Jump to paypal site and wait for it to get back.
Stripe
Gosh, we still doesn't have it in Brazil. :(
Billet (Banking) I think this is something we only have in Brazil. It's is a document (like a bill or a fracture, here's an example: Billet) you can print at home (it has a barcode) and pay at your bank (online or in person). Payment is received in our bank account a couple of days after payment, so there's nothing we can do, just show the document and wait for a payment that may never happen:
Just open a new window with it, customer may print it or not.
And, of course, for each step there might be decisions to make, problems, error messages, retries in case of errors (credit card may say "try again" and I must ask the user if he wants to do it).
So how would you achitecture this, in terms of (mainly) views, controllers and services (or repositories or libraries...), the way we can at anytime add more payment methods to the list. Are there any Design Patterns (to add to the Repository Pattern) wich would help to design this kind of interaction?
If you want to save the request in a queue you can use Command pattern.
As per my understanding in this scenario after getting the credit and debit card detail we will swipe then we will jump paypal site then we will have the Billet these are sequence activity or these are request queue here we can use Command pattern and for the different pages of your credit card ,debit card etc we can use factory class to get the instance of credit and debit cards etc.
Modifications are welcomed.
Related
I am currently planning a new website for a local car hire company. They want a form where a user can input their personal details, select the car they want to hire and when they want to hire it etc. They do not want to take any form of payment on the website, but still insist on taking the user's credit/debit card details that they will then process on their card terminal at the time of hire when the customer picks up the car.
I have looked into a few options about how to achieve this, but keep stumbling on the card details gathering point. One option I have looked at is using WooCommerce (I am building on WordPress) along with this plugin https://www.wplab.com/plugins/offline-credit-card-processing-woocommerce/.
I am looking for any suggestions on a suitable and secure way of gathering the card details with this reservation form, with or without the use of WooCommerce.
Do everything you can to avoid taking credit card details, especially in the case where you're not actually performing any charges against them. Otherwise, you open yourself up to a whole new world of pain, the least of which is ensuring that your whole system design is PCI compliant.
I would try to find out why they think they need the card number ahead of time. When the customer gets to the physical location, the business will get a lower rate from the payment processor if they perform a card present transaction, which means it's actually cheaper for them to not collect the number ahead of time. That alone should be enough of an argument to sway them. If they insist on still taking the card numbers offline, hit them with a huge quote to make your system PCI complaint. It is no joke.
Use a secure SSL connection for a start!
Try a Credit Card validator such as https://framework.zend.com/manual/2.4/en/modules/zend.validator.credit-card.html
This might be quite a long read, because there is a bit if relevant back story. Of you just wanted to see the question summarized I have it written at the end.
Edit: I realize hiding the type of business isn't useful, it's a maid/cleaning business.
I'm working with a client where the service they provide is ordered through the website, but the client doesn't have to pay until the service is finished. Because of this the payment is handled through a third party and no payment information is even processed on the website.
The problem is now with the city. While we were in talks with them to obtain a license for the product they said that we could still collect payment the way we want, but we have to store(or have access to) a credit card for each user so we can identify or track them if they break a law (like assault one of our employees on the job or decide not to pay or whatever)
Originally we thought a fully varied phone number would be enough but they are insistent that we need to be able to link a user on the website to a credit card. Even if they choose to pay by cash we need a credit card on record just in the off chance we need to track them later.
Is there a way to do this without holding credit card information on our personal database? When a user makes an account can I ask for a credit card at that point and then just feed it to a service like stripe and just hold it there sort of acting like a second database? If we go through this route is there anything we need to do on our side in regard to PCI Compliance.
Our owner has had a bad experience in the past with bad developers holding credit card data on a server that was not protected and it ended badly so he refuses to hold any card information on our side Also the insurance we have already lined up refuses to back us any further if we hold it in site without professional security measures. Even if we did start to hold credit card information, what exactly do I have to do to make sure it's all secure and up to standard, I've never had to handle this before.
Any suggestions or help would be awesome I'm really stuck here.
TL;DR: City wants us to be able to link a user to a credit card before service is even started, so basically upon sign-up. Owner of business and isurance company doesn't want to save credit card information on our database. I'm not sure how to handle this and make both happy. Do I learn some basic encryption? Can I use stripe or something as a second database?
Edit: To clarify further, I don't want to use any of the information we save, we plan to charge customers differently. The city just wants it on record.
Yes of course there is a solution.
There are companies (Payment processing companies) that are doing exactly this, they charge a fee and offload all of the responsibility from you.
They invest a lot of money to be able to validate all of the security measures required by the law, including PCI compliance.
Those companies are not only offering different payment formats (such as single payment, recurring payments, etc..) but also takes care of storing some data on their side for future payments from the customer.
stripe, 2checkout and authorize.net are only a few of many options to look into.
Don't you ever think about storing any sensitive information (credit card information is only one example) on your own servers, unless you can comply with all security measures required by the law - which is a tiresome and expensive thing to do.
Good luck !
I need a payment gateway for my php application.I am running a software consultancy and employees are from different parts of the world. I have build an application manage invoices and pay money to them. I need this to be integrated with a payment gateway.
My organization is in USA.
I checked with some payment gateways, but they need seller account for each employee.That is not possible.
My direct requirement is the cash must be transferred from my card/bank account to my employee's bank account . I want to pay through net banking,credit/debit cards,wired transfers,etc.
Please help!!
Thank you
If your requirements are such that the employees need to invoice you first before they get paid, I don't know how you can get around the seller account requirement.
However, if all you're trying to do is simply pay your employees, and manage their invoices through a separate system, something like PayPal could work -- I think really any payment gateway could work if you could push your requirements to the point that you simply pay your employees (one process) and handle client invoices through a second process.
Last time I checked, Paypal lets you transfer to family and friends without their percentage charge, which you could possibly bend to meet your employee payment requirement, if you can offload the invoicing piece to a separate system.
First, you don't tell us enough information about your requirements: do you need support for physical goods ? if so - who's doing the fulfillment ? you can't charge a credit-card until the package was sent which makes things more complicate than most people are aware of.
Second, what you're referring to is called the re-seller model. This model is problematic since all the major credit-card companies in the US recently came up with a new requirement: a merchant that processes more than 100K a year should open his own merchant account! (that's part of PCI compliancy required from the processors).
If all you need is to pay your employees, and being able to do so globally, there's a cool company that does just that called Tiplati.
Disclosure:I work for one of the major payment processing solutions called Bluesnap
Our implementation language is PHP (using the CodeIgniter library).
My requirements are this:
Users need to be able to RSVP to events, at which point we put a pre-auth on their card. 24 hours before the event, we take the payment from their card. Up until 24 hours before the event's start time, the organiser can cancel it. In this case, the authorization on the card is released.
Are there any SaaS services that can remove the hassle from all this logic for me? Even better - provide a secured, hosted form page on which the user can provide their CC details (removing the need for me to have anything to do with credit card info)?
Competitive pricing model definitely a plus.
As profitphp pointed out. That's not quite how it would work. The auth typically drops off within 2 or three days if it has not been settled.
So instead you would capture the card details upfront, by redirecting the user to a page hosted by your Payment Service Provider (or PSP which is the lingo for SaaS when it comes to payments). When capturing the details you want your PSP to perform a zero value authorisation, which will just confirm the card details are valid, and then return to you a token id.
24 hours before the event you then run through the list of all tokens that haven't been cancelled and submit them to the PSP again, but this time performing a full auth/settlement. There is a reasonable chance though that some of these will fail to auth (lack of funds or expired/canceled cards being most likely), so you need some business logic to handle that.
Alternatively you could perform auth/settlement a week before the event, which would allow time to recontact the customers where auth has failed. You would still be able to offer refunds by submitting the token id to the PSP.
Mostly any Payment Service Provider will offer this functionality.
groupon.com is a great example when you register they take your credit card information. once a limited amount of people have purchased a coupon a mass amount of credit cards get charged. what is the best method of doing something like this and at the most safest possible way? one thing that i will be doing is encrypting the credit cards in the db with an encryption method that salts the encryption and that i can unencrypted it to use it when needed. would they possibly have a cron that goes through at a period of time to check and see if the coupon time limit has expired then do a mass charge? i cannot wrap around my head to how something can be written that queues transaction charges to a merchant. i am thinking of either using authorize.net or paypal pro.. what do you think from what ive said?
Don't store the credit card information on your server. It would need to follow PCI DSS security standards:
http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard
There's just no reason for it these days. A large percentage of payment processing vendors provide these services for you. You submit the information and receive back a token that can be used to charge the card at a later time.
Furthermore, you are not allowed to store the CVV code.
I personally work with Paypal as the processor, you need to request reference transactions (this will require a background check, probably credit worthiness related and is not guaranteed to be approved). In this way I can authorize a card ($1 authorization only is common and accepted practice) and later charge the card any amount that is appropriate (in our case we have a payment model similar to pay-as-you-go mobile phones). Upon the first charge or authorization I receive a token that I can late use to charge against the "referenced transaction" (essentially just copying the details from the original txn).
Another really interesting option that we looked into was www.paysimple.com, they now have a new API, an attractive pricing structure, and if memory serves, all of the above features.
Many others exist as well that you can and should research. Do watch out though, some card processing providers don't charge anything for the functionality described above (paypal doesn't), but some charge gobs of money for the service. Look, it's generally readily available info on the sites.
Start reading PCI Compliance and periodical payments parts of the source code of an open source cart like Magento. There is a lot to it, if you want to do it all properly.