I am working on an apartment CRM of sorts and I would like to allow renters to be able to pay bills online. My issue is that I don't know how you would implement a system that would work in this case. I would both need to accept payment from landlords/owners for providing a service to them and also allow them to collect rent from their renters(users). Any tips on setting up something like this? For the accepting payments from landlords/owners part, that is pretty straightforward as I would just need to integrate some payment gateway but the other part has me stumped.
For security and accountability reasons I don't want to be responsible for moving funds myself from the rents collected to each individual owner. I would like to keep each payment relationship (landlords and renters) separate if that makes any sense.
In case it matters, I am using the PHP framework CodeIgniter for this.
Here's the challenge...when you're talking about removing yourself from the money moving game, I believe you're talking about multiple merchant accounts. Now I'm sure that there's some sort of discount out there for running multiple accounts, but generally the merchants aren't your friend unless you're doing some serious traffic--the last merchant account I worked on did about $1million USD/year and we still didn't feel like we were very high on the totem pole with customer service or negotiating position for merchant fees. You'll be talking about $30/month (give or take) plus a percentage of the transaction as the cost to operate the merchant account.
Fees add up in a hurry. Not a problem if you're doing volume, but if you're only talking 25 renters and then only a portion of them use the service, you may get hit harder that you can justify with them spread amongst multiple sites.
Consider some already done options out there:
https://www.erentpayment.com/Default.aspx
http://www.landlord.com/rent_collection_online.htm
http://www.rentmatic.com/
Obviously, I don't know the specifics of your situation, so these may not be a great option. Regardless, it never hurts to explore alternatives if only to learn what UI patterns they used to achieve the goal you're shooting for.
You'll have to set up some sort of payment gateway account for each owner. You can save their settings for the gateway in your database.
Related
The example scenario, to provide context here, is an app (iPhone, Android) that pays the user (using Paypal) to do certain tasks. It currently operates under the assumption every user behaves and has a single account.
UPDATE - To clarify how these tasks work. Each user can do a task once, but tasks can be performed by multiple users. This is why I need to make sure a user really is only doing a task one time.
Example Task
Your testing product will arrive in the mail shortly. Please use it for a week and then supply your feedback. Upon completion of your feedback, we will give you $2.50.
The issue comes up when a user makes multiple accounts, and then attempts to pay out on these multiple accounts to earn a lot of money quickly. So as a result, you can see this app needs some way to detect that a user is taking advantage it.
Right now our tools for identification are as follows:
Weak Identifiers - Things that are subject to change, and are easily faked.
First Name
Last Name
IP Address
Email
Strong Identifiers - Things that are more difficult to change or fake, but still possible to do so.
IMEI (Android only)
Paypal Account (only good after first payout, user could mass payout before it mattered)
Advertiser Id
Unique Device Id
Push Notification Token (for app notifications)
Based on these identifiers, and being completely ignorant of the processes used to link accounts together with them I am curious if anyone has advice for doing this type of matching. Also knowing that many of these things can be forged by a devoted person.
For emails, there are ways to fuzzy match but they are quite slow. I have ways of getting some of this done already but I want a best practices and experiences from others before I move further down this rabbit hole.
I am aware there is no 100% surefire way to detect duplicates, but all I want to do is flag the possible duplicates for review and give an administrator the power to review the accounts and either merge or disable them.
UPDATE - Paypal
Paypal is a good source, but it only works in very specific cases. To check for a verified account and get the account id back you must have the exact same first and last name on the account provided by the user. This is not always the case. Jonathan could be Jon, Christopher could be Chris, etc. Also, multiple emails can be tied to the same account. So a couple could be sharing and it makes little sense to force them to enter in someone else's name in order to submit their payment.
As for the payout return, this can be avoided by paying out all at once on many accounts. Thus there is nothing to detect until after the payment has already been made. I am not aware of a good way to cancel payments via Paypal so if there is a suggestion there I am all ears.
I wanted to follow up on this and mention that while I didn't get a solution for this particular item I did get an answer.
Bank accounts/credit cards (which translate to paypal accounts in this case) are probably your best bet at limiting multi-accounting. You will not cover 100% of the cases but its better than anything else. The second best are phone numbers. Other than that its a endless race between you and people who spoof device identifiers or reverse engineer your network protocol and bypass the app entirely. - #Vatev
Just to resolve this question, the reality is no matter how hard you try to fingerprint a device there are ways to get around it. The only reliable way is to have a lower level access to the phones, a level of access that Google and Apple do not provide and the only alternatives will get your app rejected for misuse of the service.
I've been going round in circles looking at Paypal's convoluted API docs trying to work out exactly what I need to be doing.
I have a PHP website that has its own cart already developed, and now I need to integrate Paypal with it.
What I want it to do is allow buying multiple items from multiple sellers and dealing with them all in one transaction, while allowing the oppertunity to adjust postage cost once the buyers address is confirmed.
So far I've gotten a barebones single amount single seller transaction nearly working, using PHP from Paypal's integration wizard, however I'm not having much luck getting that working properly (or understanding what's going on) - I've given up trying to debug that and am currently poking bits of the API on the sandbox to see if I can decipher what I actually need to do.
I'd ideally like to see a good how-to guide from someone who has already done what I'm doing, or a link to some further reading that is less vague and more example-rich than paypal's docs.
I'm sure it's not just me but I have a hard time reading a description of what some code should do compared to reading the code itself.
Any nudges in the right direction are much appreciated
I assume you're using the PayPal NVP / SOAP API?
What you describe seems to be what the PayPal Adaptive Payments API (documentation) tries to accomplish, I've never messed with it personally but I'm pretty sure that's what you are looking for:
Send simple payments to a single recipient.
Make split payments to multiple recipients.
Send chained payments to multiple recipients, one after the other, each of which can take a cut of the payment.
Make parallel payments to multiple recipients at the same time.
I am creating an ecommerce site that uses the payment gateway DPS. The payment gateway just takes a users details and returns whether the payment was successful or not.
I am just wondering if anyone has any good resources for how to make a really robust payments page that can handle large volumes of transactions safely. Are there well tested techniques and strategies for high volume payments pages?
You'll want to design your code in such a way as took keep your data in a valid state.
The big liability you face is that you send data off for Auth/Capture, and then, for whatever reason, something on your end fails. You've charged your customer, but for whatever reason, you don't know this fact! Eventually, some irate customer is going to start shouting at you over the phone. That's a bad time.
The general idea is to put some safeguards in place so you can identify these kinds of problems. The problem should be very rare, if it even ever happens, so fixing the mess will probably be a manual process.
Here's what I would do:
Design a database table that tracks payments (let's call it "payment"), and relate it to your "order" table (so payment.order_id references order.id).
When it's time to interact with your gateway, set up a new payment record, containing any non-sensitive data you're about to pass to the payment gateway. Have a "status" column in your payment table, and set it to "pending"
Attempt the auth/capture transaction with your gateway. Upon receiving a response, update the payment record status to "approved", "declined", or "error" and save any relevant metadata (decline reasons, transaction ID, etc). If the gateway times out, that's probably just a kind of "error", though you might retry once or twice.
Run a cron job every now and then looking for payment records that are "pending", and older than, say, 30 seconds. If you find any, panic and tell a developer/operations person.
There are certainly other things that could go wrong, but this is the big one that comes to mind, and the strategy I've described is one I've used on multiple occasions to mitigate the risk.
I'm not an expert on payment processing and developing ecommerce applications, but some of my (commonsense) guidelines are:
Force HTTPS for the submission of CC information from users (pretty much all payment processing gateways force the use of SSL when communicating with their gateway);
Do not store Credit Card information in the database after processing;*
Follow general security guidelines (e.g. don't save plain-text passwords or e-mail passwords);
*Note:
PCI does allow for the storage of credit card details after processing, but you need PCI-compliant hosting, which is usually quite expensive. And even then you're running a huge risk. So if you decide to give your customers that option (and I know it's very tempting since big sites like Amazon all offer "one-click" checkout), you better make sure your application and server are locked down tight.
I don't know much about scalability issues with payment processing as I have no experience in that area. All of my applications only process about 5-25 orders a day.
Use SagePay (formerly Protx) it supports PayPal and allows you to take card payments. It also integrates into the Sage Suite (an accoutants dream) it can automate a lot of time consuming data entry.
www.sagepay.com
As others are saying - Sometimes for smaller sites it's not worth taking the risk of storing cards yourself. I prefer paying on websites where I'm redirected to a well known payment service (such as paypal, sagepay or google checkout) as i know that a lot of money is spent on securing this software. If you're a website that i'm using for the first time, well I'm going to be put off.
I was given the task of creating a registration page for an upcoming church retreat. Design-wise, it will consist of fields for name, sex, phone number, email, and grade. We need a way for the end user to put their credit/debit card info and have it charge them for the retreat.
After some searching I found that Braintree offers a good service (37 signals likes them). The down side is that I have no clue on how to implement this sort of system into my site. So we are going to apply for a merchant account using their service. I also found documentation on how to implement it with PHP.
My question is, do I have to do anything else? I've always heard of https but I don't know if that's something I should implement. What security measures should I put in place? Should credit card numbers be stored in a database as plain text or encrypted? Has anyone used Braintree and can let me know what to expect after getting a merchant account?
Edit: I was looking through the PHP documentation code and was lost at this:
Braintree_Configuration::environment('sandbox');
Braintree_Configuration::merchantId('your_merchant_id');
Braintree_Configuration::publicKey('your_public_key');
Braintree_Configuration::privateKey('your_private_key');
I'm guessing the environment is set to sandbox for testing but is a merchantId provided to you after you make an account? Also, I have no idea what a public or private key is.
Hire someone with ecommerce experience to do this. If you don't know what https is then you shouldn't be handling sensitive information like credit card numbers or processing payments. The implications of a poor implementation are huge and lives can literally be ruined from it.
Do not store the credit card information in a database. This is a bad idea for numerous reasons listed many places on the Interwebs. PCI Compliance being the most commonly cited one. It is a really, really, really bad idea.
Https, by the way, is the secure version of the http protocol and allows for http traffic to be encrypted between clients (usually a browser and server but not always). It is implemented by the installation of an SSL certificate.
Your best bet is to use a merchant account and a payment gateway service like Authorize.Net's SIM API which handles the order form for you. That way you hand the handling of sensitive data to them.
You may want to read Merchant Accounts 101 and Ecommerce 101 before proceeding. Disclaimer, I wrote those articles.
You should not and cannot store any credit card information in your database. Mostly any payments service like Braintree will handle entering sensitive data, HTTPS and all other things. All you need to do is to give correct request to payment gateway and process answer.
A second reason to consider a site such as Google Checkout, Amazon, or Paypal is because the big merchants charge a set fee by the month plus transaction fee. If this is a one-time deal, the registration fees aren't that significant, or you don't plan to use it year-round, it's likely not worth going this route, even with a professional doing the work. I do a lot of work with quite a few smaller non-profits and the only way they can afford to do merchant accounts is via grouping of resources...but that brings up several tricky accounting questions.
Even easier than doing all the work yourself, consider a simple online registration site such as Active.com (or many multiples of others out there--I'd bet there's even one specifically for church groups) Their business is online event registration, and they do this for hundreds of smaller parks and rec type registrations, so they certainly would have the capability to do something like this. Trust me, having built several registration systems, there's nothing worse than the first bug popping up that makes 50 registrants show up unregistered or charging someone 4 times.
Unless there's some good reason for you to roll your own, use a third-party service to handle registrations for you. Among the others mentioned, some of my friends who put on shows and improptu classes use eventbrite.com and brownpapertickets.com
Both will tack on a small service fee
I am currently selling time based access passes to an online service at micro payment prices.
After payment the customer gets a set of credentials that is only valid for the purchased period. When the access pass expires the customer has to buy a new set of credentials.
So basically the credentials are one-time(period) use only.
I would like to offer a free-trial of x minutes to this service so potential customers can realise it works fine, possibly increasing total sales.
My question is, how would you stop abusers?
That is, people should only be allowed to try for free once, and if that is not possible at least make them go through a process/test which (as in shareware) is too cumbersome or annoying for them to keep trying it.
Obviously there is always someone who will bypass it. I am looking for a solution for the majority of people who are either not IT savvy, time constrained, or simply too lazy to bother abusing it, instead of simply paying the tiny fee.
I have some approaches in mind but would like to be inspired by other people too.
The service is developed with LAMP.
Put a cookie in their browser. Force a small delay before they can re-use your service, or make them go to the trouble of deleting the cookie. If they block cookies, politely ask them to allow them. You might have more business success if you allow several trials, with a minimum of hassle.
If you look around, everybody who gives out free trials binds them to a credit card - not to charge them, but to verify the user's identity. That's about the only feasible way to prevent abuse I can think of.
Any other idea will depend on the kind of service you are offering. StackExchange for example can offer a 45 day trial without a credit card no problem, simply because the effort to build a SE site is so huge, starting multiple trial periods (and having to configure a new site and build a new community every time) just wouldn't work.
Something similar could be unique login names that you can register during your trial period, and would have to give away if you don't convert it into a pay subscription, things like that. Really depends on the nature of your service.
The users who want to try your product again via a trial are highly convertible users because they already know the value of the product.
The challenge is detecting them and then converting them to paying users.
Detecting can be done using a variety of signals including:
IP
Cookies
Device fingerprints
Credit card or payment information
Email verification and validation
Each individual signal has its challenges eg. IPs can change and are legitimately shared among large audience such as via carrier grade nat.
SMS verification is good in most markets but adds friction and potentially cost for you and your users.
Something like Upollo.ai solves all the hard parts for you so worth a look for people facing these problems in future
I ended up using the smallest possible payment amount for a short time span, but enough to get the user satisfied at very low monetary risk.
In the time past since I asked I actually seriously considered using Flash cookies which very few people know (even that they exist) how to remove.
The other simple (although not-free) is using a SMS confirmation option which binds the user's mobile phone number. As a mobile phone number you just do not throw away like you do with email addresses then this is also a safe limitation method.