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.
Related
I've already been in discussion with many many different payment providers and I'm getting tired of endless meetings and discussions, which in the end end up that the support or their sales department was hiding a flaw in their system / confirmed one of the features below that is actually not possible; and you have to look for another provider, reprogram the entire integration with a new provider, etc.
So I wanted to ask here; does anyone here know ANY payment service provider which is compatible with a PHP + MariaDB backend, and with mobile apps as well (via Rest API calls) that have all of the following features:
Secure.
Register a Credit Card for a customer via a custom form submission; ideally send data to payment service provider via js, receive an according token from them, and store that token within your DB. Like this, your own server does not have to be PCI compliant.
Every time a customer X clicks a specific button on your website, after authenticating the request on your backend, use your token to trigger an according payment within your backend (with secured public key authentication, etc.)
Every single payment the customer X realizes has to be only authorized first ( = validate card + verify that clients has the funds, + freeze them on the card), and captured after the customer X received the booked service, days later.
The authorize and capture mechanisms must work for every single payment with the obtained payment.
refunds of captured transactions must be possible.
The KYC procedure of service providers who receive payouts has to be possible for individuals, not only for companies (believe it or not, some providers only provide company profile possibilities for payouts..)
The Service provider must ideally be internationally active, i.e. with low currency switch fees.
Split Payments must be possible (e.g. marketplace - style, customer pays fee for service to company, company takes off commission and forwards rest to service provider)
Not sure how the PHP + Maria DB has anything to do with your inquiry.
You are calling a RESTfull API, call it with any technology you want.
Most of Your requirements are pretty straightforward and can be answered by many providers.
The challenging part on your question is more on the international market place part. Which mostly depends on the KYC you mentioned, and highly depends on the country the merchant is in and type of goods you sell.
KYC for market place sellers, payout methods to sellers and so forth are heavily regulated and might be complex in multi country mode.
In your search I would explore this topic in depth.
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.
I have a recurring payment solution set up via PayPal's IPN service, basically the user fills in a form, pays the money and via IPN my system gets a ping to grand the user access to the system.
Everything technically works fine, but occasionally on the last day of a user's cycle they forget that it is a recurring payment and complete the form again. PayPal doesn't seem to mind this and creates a second recurring payment profile.
Currently I go in, refund the money and cancel this new payment profile, but obviously this isn't ideal - is there any way I can configure PayPal to not accept new profiles from people with currently active profiles? Or will I need to catch this at my website's end and do some form of lookup before allowing the payment?
Paypal did not recognize the a transaction is a duplicate one, It tackles the transaction as a new transaction. You will have to tackle it from your system.
When implementing payment gateways, It is good approach to save the billing with a status pending or something in your system before sending to payment gateway.
Also in the form user is filling you can implement a field to uniquely identify the user like his email address and you can also save the expiry or second recurring date against the user unique field in your system. Now when the user enter the same unique field and want to submit a form again you can validate that the same user is paying again but its expiry of second billing date is not yet reached, so prompt and restrict him for paying again.
Hope it will help you.
I'm working on a project with a new client and they've had some problems getting a merchant account for processing their online payments due to the business type. The system works in a similar way to Just Eat/Expedia etc in that a customer places on order on the site which is then passed on to the venue, with the site taking a commission.
The client asked if we could store customer payment details in our database (encrypted) and then pass them on to the venue for processing themselves using their in-house card systems. I know there are PCI Compliance issues with this but I've not been able to get a straight answer on exactly what we need to do. I've spoken to a couple of hosting companies and one is saying we need a cluster with separate web and database servers, while another has said we won't. I've never done something like this before, I usually just farm out payment processing to somebody like SagePay etc.
This is the proposed payment flow:
Customer places order on website
Payment details are stored in database
Customer is emailed an order acknoledgement. Venue is emailed an order notification. If venue accepts the order, order and payment details are transmitted for in-house offline processing
Once the venue has taken payment in-house, the order is confirmed and payment details are deleted from the site database
Customer is emailed a final order confirmation
I want to make sure any process is right, and the last thing I want is for the site to be attacked, payment details taken, and be left liable for any losses!
Any advice would be much appreciated.
You failed to include an actual question....
However: PCI compliance is non-trivial; there are multiple levels of compliance, and the standards are a little dense...in general, as long as you don't store payment details, it's relatively easy to comply. If you do store payment details, your compliance requirements become a lot more complex, and may include processes such as vetting employees.
Your intention to transfer payment details to the venues looks like a huge red flag - you're basically giving credit card details to third parties, which I as a consumer would not be happy about, and is almost certainly not allowed within any of the PCI standards.
It's worth talking to a specialist payment gateway provider about the options you have - for instance, most credit card transactions consist of an "authorisation" call, which submits the card details and amount; the service checks the card is good for the money, and "ring fences" the amount on the account, and issues back an authorization code. The actual "settlement" can occur later - up to 10 days for some cards, and can use just the authorization code, rather than the full card details. A specialist payment provider will know what options you have.
It may be possible for you to share the authorization code with your venues, to allow them to take payment (though this would almost certainly require you all to use the same gateway provider).
It would be straightforward to change the flow you mention to include auth/settle logic:
Customer places order on website
Your site issues "auth" using credit card details, store auth code.
Customer is emailed an order acknoledgement.
Venue is emailed an order notification.
If venue accepts the order, you execute the "settle" transaction
You confirm order details to venue
Customer is emailed a final order confirmation
Weekly/monthly/whatever you issue a report to each venue showing amount outstanding and send them a cheque or whatever.
An alternative approach is to take the storage of credit card information out of your hands completely and put the burden on someone else who has the means and expertise to do so while making it easy for you to charge your customers when necessary. Authorize.Net offers their Customer Information Manager API which allows you to create payment profiles for your customers. They handle the storage of the credit card information and give you a payment ID for it. You then can charge against that payment ID whenever necessary without having to have access to the actual payment details.
I'm currently creating a system that lets admins create events and allow individuals to register for those events. Each registration has a fee associated with it, which registrants pay using PayPal. When an event is created, the admin inputs the PayPal account for which the money will be deposited. I then charge a set price per registration as the fee for the service. Is there a way to automatically take my cut of the fee when the payment is submitted to Paypal?
I've looked at the Mass Pay option with PayPal, but that means all the money has to go into a central account and then get divided out from there (if I understand it right). I would rather stay away from all money going into a central account, as there gets to be a lot of liability involved there.
Now, I'm not 100% tied to PayPal, so if anyone else knows of another service that would work, I would be glad to hear about it. I'm sure someone else has run into this before...
Look into Paypal Adaptive Payments. It allows for payments to be sent to two parties.