Are there any mobile-friendly Credit Card billing solutions for mobile sites similar to Bango?
The advantages of Bango I have seen compared to regular Credit Card solutions that make it considerably "mobile-friendly" are:
1) It does not require the user to enter their full name and billing
address to make a payment. The user is only required to enter their
Credit Card number, expiration date, and CVC code (if they are in
the U.S., they will also have to enter their Zip Code). That is significantly less input than is normally required for Credit Card payments, which is a big plus on small mobile key pads.
After a user makes an initial Credit Card payment, their details
are stored by Bango, and the next time the user needs to make a
payment with the same Credit Card, they just have to click a single
link and it processes the payment on their stored Credit Card.
Needless to say, this is very convenient for mobile users as it is
analogous to Direct Carrier Billing as far as the user is concerned since they won't need to input any details.
The downside with Bango is that their fees are higher than others, all payments must be processed via their site and branding, there is a high minimum ($1.99) and a low maximum ($30) on how much you can charge users, and you need to pay a monthly fee on top of the high transaction costs.
It is due to the downsides mentioned above that I am looking for an alternative solution that also does the advantages 1) and 2) above. Is there anything like that? I looked at JunglePay and they do neither 1) nor 2).
We, Balanced, have simliar functionality to what you're looking for. Card number, and expiration are the only required information. However the more information you gather the better that fraud detection can happen, only asking for the minimum could open you up to chargebacks and the cost associated with them.
The second requirement you mention is a feature called card tokenization and most card processors should support this functionality.
Balanced is not inherently mobile focussed. It's a REST API so whatever you serve to the customer is up to you. You, as the developer, would create a webpage that takes in the card information, tokenizes it securely, and then submits the token to your server where logic in your application makes the charge whenever you're ready.
Related
We have a micro service which is used just for handling user's orders. Right now, the payment provider we use, Stripe, stores these payment methods but we need to use some of the data from these payment methods like sending emails to the user before their card is due to expire so we need to store these cards in an internal DB table however I can see data quickly getting out of sync.
But if we call Stripe directly, if we ever end up switching payment providers we'll be very much tied into Stripe as all the payment methods are stored in there and they'll all be cleared if we ever left Stripe.
So the question is, if you were to do the same would you store payment methods on just Stripe and be tied in or also on an internal DB and just allow the data to get out of sync?
I would be very careful about storing cc info in your system unless you have to. Once you do, you will have to become PCI DSS compliant, which adds considerable cost and regulations to your operations.
Storing an expiration date and the last 4 digits of the card are acceptable, but if you store enough to move providers (like the full PAN), then you will need to maintain PCI compliance.
This may be worth it, but you will have to decide for yourself if the flexibility is going to be worth the additional overhead.
I'm creating a website which has a premium user feature. I'm thinking on how to design the database to store the premium user plan, and how to check it..
My main idea so far is:
Having 2 fields on the user table: premium (boolean) and expires (date)
When user does payment, it will calculate the plan duration, set premium to 1, and the expire date to the end of the duration
Every time I check if user->isPremium(), it will also check if it's expired.. if so, set it back to zero and offer a renewal
Aside from this, all payments /transactions will be recorded in a logs table for record keeping.
This is a simple design I thought, but since this is a common feature on many websites, I thought of asking you guys how do the pros do this?
This probably won't make much difference on the design, but I'll use Stripe for handling payments.
It looks good to me. It is simple and solves your problem.
Hint 1: Depending on the semantics of your premium and expires fields, you do not need both. You can just change your user->isPremium() to check if the expires date has passed. Make sure you also change how you handle offering a renew.
Hint 2: I am working in a system that handles plan subscriptions and I had to deal with the following cases:
Permit users renew/extend the subscription before expiration date.
Different prices for different durations.
Discounts.
The delay between bill generation and payment confirmation.
Users with pending payments trying to buy again.
Users asking to cancel current subscriptions.
Hope it helps.
I´m working on a service where users will have several purchases (each ranging from ~5€ to ~20€) over the course of a few hours within an app.
Instead of processing each payment individually with fees occurring each time I would like to bundle those and execute them together (let´s say after 6 hours).
The apps will be for Android and iOS with the backend on Google App Engine.
The Paypal Preapproval feature sounds in theory like what I want. But this thread PayPal PreApproved Payments makes me think that the risk is high that many of the payments will fail?
Is there a solution around which actually guarantees, that the payments will happen in the end?
I would be open to other services than PayPal as long as it is easy for the user, has affordable fees and guarantees that the payment will occur in full.
Thanks!
"Preapproval" means you are collecting the user's approval for future payments rather than getting their agreement with each payment; you are correct that this does not guarantee their ability to pay. Someone can agree to be billed but not be able to pay the amount they are later billed.
You can get a "soft" check of their ability to pay in some PayPal APIs (depends which specific PayPal product you are using), but without a guarantee. This soft check simply says "if I were to ask you right now for $10, would you probably be able to pay it?" Useful, and has ZERO impact to the customer: no additional UI for them; they won't see the amount; and they will see nothing in their account after the check. This will reduce your risk but not eliminate it. Suitable for cases where you are willing to take a low-single-digit failure % and either forgo those sales or follow up with the customers whose payments go bump.
If you need to guarantee that funds are available, and hold those funds against future purchases, you must collect an "authorization" from your buyer. An authorization places a hold on funds in the buyer's account. This means that a) you must know how much to request, and b) the buyer must see and approve the authorization transaction (unless you previously collected preauthorization agreement) and c) the authorization visibly holds funds in their account after they approve it.
This is basically the same for credit/debit cards and PayPal, although the details differ a bit.
A single authorization can, with some limitations, be used to complete multiple separate purchases, although in this case fees will be charged for each resulting payment. Or you can track how much liability a customer is actually stacking up and make one bundled capture (aka payment) at the end, thus potentially slightly reducing your fees. (With PayPal at least you would pay the per-transaction component of the fee only once, and the % would be the same. With other processors, using authorizations this way usually carries an additional auth charge plus exposes you to escalating fees when/if the total amount captured is not exactly equal to the amount authorized or based on the elapsed time between authorization and capture. It's very complicated and can be hard to determine when or if you will actually save any money.)
One other difference between PayPal and other processors: there are a few edge cases where PayPal will decline captures even after you authorize. PayPal only guarantees you a limited amount of overage. So if you authorize for $10 and capture for $12 you are OK, but if you authorize for $10 and capture for $100 PayPal will complete that for you if the buyer can, but is NOT guaranteeing success. And no security is perfect, and if for example PayPal happens to discover between the time of the auth and the time of the capture that the sending account has been compromised (stolen), they will freeze it and decline your capture. This is a vanishingly small %, but it CAN happen. So it's a 99.9% guarantee, but technically not 100%. (A credit card company NEVER fails a capture operation, so in this case would complete your capture... but likely send you a chargeback to take the money back from you later.)
We are building a service that utilizes the Gmail API. In order to understand our costs as we scale, I would like to know how much it costs to use the Gmail API. I've followed the instructions at https://developers.google.com/gmail/api/v1/reference/quota through to the point at which it says:
If you have enabled billing for your project [we have], clicking Quota
takes you to a page where you can view and change quota-related
settings.
The only option on that page for changing our daily quota is to "Apply for higher quota"; however, clicking that opens a window that says:
Please be sure to review the existing quota limits to confirm you need
more than the daily default.... If you simply have a question on limits, please ask it on the Stack
Overflow forum
Thus, I am asking here: what is the cost per API unit when one's needs exceed the daily free quota?
The API isn't marked as "billable" meaning it's free up to a limit and there's no set/published pricing above that. If you are using your existing quota or are getting close and want to ask for more, I think best place is to ask on the quota request form. It's quite reasonable to ask for quota to provision for a few quarters of growth IMO and if you're migrating from some other API (e.g. IMAP, atom feed, DOM hacking) then obviously that should be quite reasonable to provision all that beforehand as well.
Would it be possible to build a Ticketmaster style ticket reservation system by storing all information in a Cassandra cluster?
The system needs to be able to
1. Display the correct number of tickets available at one time
2. Temporarily reserve a ticket while the customer is making the purchase
3. No two users can ever buy the same ticket.
For consistency all reads and writes should be made at quorum. I'm not sure how to implement steps 2 or 3?
Yes, you can.
However, there will be some transactions where you want strict consistency. For example, consistency does not matter when the user is browsing the site and adding tickets to their shopping cart, but when they checkout and select a specific seat number on a specific day consistency matters a great deal (double bookings being a bad thing, especially for high interest events).
So, you could implement 99% of the functionality in an eventually consistent database and implement the checkout process in a consistent database. This is also nice because you can scale 99% of your system that likely gets >70% of the load horizontally and across multiple data centers. Just keep in mind that you will have to deal with the scenario of your site being up but your checkout process being down (ex., an error dialog at checkout asking them to wait/retry and giving them a promo code for their troubles).
The last detail is that you will need to update your eventually consistent database's "number of available tickets" after someone checks out. The good news is that this can be done lazily - queue up that job and do it whenever your system has some spare cycles. It certainly never has to happen in the critical path of the user's checkout process.