Context
Me and my team are developing solutions to allow merchants with an online store to more easily deal with in store payments.
At the moment we are also considering the option to develop our own POS terminal integration (based on off-the-shelf EMV L1&L2 Certified rebranded terminals) to give a more coherent user experience to our customers.
On our online solution we support recurring payments using Stripe as our payment gateway therefore we would like to extend this option to physical stores as well.
Of course we could make it possible in the same way we do for online customers but we would like to make the payment experience as similar as possible to the one customers have when purchasing a one time payment product.
Questions
Can a POS terminal setup recurring payments?
Maybe through some trickery that allows to authorize a payment on the spot but capture it in a second moment?
End if it isn't possible and we have to rely on Stripe for this:
Is it legal to capture from an ordinary reader (without special specifications) information as Card Number, Card Holder end expiration date from a card magnetic stripe or other medium to prefill those fields?
I'm not talking about storing those information of course, just reading them to more easily add this card to Stripe.
Thank you in advance and any quality material or alternative suggestion is welcome.
A general answer is that it is possible to initiate original transaction over POS channel and issue subsequent transactions in another (like recurring ecom). The original transaction needs to perform strong cardholder authentication and its details (Transaction ID / TraceID from authorization response) have to be indicated in subsequent authorizations.
What you are describing is referring to features and services offered by one of the companies. You should refer to their support for answer if they support it and what are conditions to do it.
Related
I've been doing some research and have been wondering how a company like privacy.com are able to generate VISA card numbers on the fly? I was looking at the VISA API and there's nothing publicly that I can find. Do they have some sort of special arrangement. I'm based in the UK and am Looking to build a service with a similar functionality, but can't seem to find any material on doing this.
Stripe also offer a service, but exclusively for US based customers. Are there any laws or regulations that I might be overlooking which prevent this being done in the UK?
VISA API
https://developer.visa.com/apibrowser
https://privacy.com/
https://stripe.com/gb/issuing
https://cards.emburse.com/pricing (These guys piggy back off stripe's service)
They probably use a service from virtual card providers. There are many, example: eNett is kinda popular with online travel agency https://www.enett.com/ They will provide you an API to create card with limit, expiration date, etc...
I'm looking for some feedback from entrepreneurs or developers that have used either Chargify or Recurly to handle their recurring billing.
More specifically, I sell a hardware device that works in unison with a companion application and charge a subscription for the functionality of the companion application. I sell both b2b and b2c. Thus, I need a recurring billing platform that can handle a single unit purchase as well as a 10-20k wholesale purchase and be able to track quantities sold. I've noticed Chargify lacks the ability for me to track quantity. Further, we have highly targeted, customized landing pages on HubSpot and would need the two platforms to integrate nicely.
Has anybody had experience with either of these platforms? What do you like and dislike about the functionality and capabilities? Which do you recommend based off what I would need it to accomplish? Alternatively, is there a different platform that you would recommend?
Regarding "I've noticed Chargify lacks the ability for me to track quantity." - Chargify is able to handle this with what they call "components." Your use case is very common and definitely doable via Chargify.
I'm currently researching making online payments through Google Wallet for a website. There will not be physical goods.
I saw that there are two very different checkout API's, inapp purchases https://developers.google.com/commerce/wallet/digital/docs/ and instant buy https://developers.google.com/commerce/wallet/online/tech-overview , but I'm not really sure what exactly the differences are between the API's in terms of when you should be using one versus the other. Can anyone explain?
Instant Buy
Instant Buy allows users to use their stored payment data from Google Wallet to purchase items from a merchant, with the merchant handling the transaction through a payment processor of their choice.
Basically, when the user submits an Instant Buy request, it will appear to your app as if they just filled in a normal order with a credit card number and everything. Google doesn't take a cut of the transaction, because Google doesn't process the payment. However, whatever payment processor you use will probably take a cut.
In-App Purchases
In-app Purchases allows merchants to have Google handle the transaction and process the payment for a digital good. In this case, Google does take a cut of the transaction because they handled the payment processing.
As far as your app is concerned, you never see payment details - Google takes care of all of that. Your app just gets a notification that user X bought item Y, and then later on, Google gives you the proceeds from the transaction.
The bottom line...
If you already have a system for handling purchases and processing credit card transactions, you probably want Instant Buy. It will sit on top of your existing infrastructure (so you don't have to have duplicate code paths) and won't cost you any money beyond what you're already paying your payment processor. It also lets your users purchase any kind of goods (physical or digital), since all it's really doing is providing payment info, not payment processing.
If you don't already have a system for handling transactions, and all you want to sell are digital goods, In-App Purchases may be simpler, since it handles all of the payment processing for you, and the cut Google takes is reasonably competitive.
For your particular case:
Since it sounds like you don't already have a payment processor lined up, and you're not trying to sell physical goods, I'd suggest looking at the In-App Purchases API.
[Full disclosure: I work for Google.]
I would like to add some info regarding the transaction fees for in app purchase. Google should put this inside the documentation, not in support section. Like Apple, the fees is clearly stated in the documentation first page because this thing is important for implementing in app purchase. For Instant Buy, no transaction fees taken by Google as you need to handle the transaction yourself. (might get charge by other party)
"For applications and all in-app products that you choose to sell on Google Play, the transaction fee is equivalent to 30% of the price. You receive 70% of the payment and the remaining 30% goes to the distribution partner and operating fees."
https://support.google.com/googleplay/android-developer/answer/112622?hl=en&ref_topic=6075663
I have a general question about accepting credit card payements.
Here is my situation:
I have a website which gives the posibility to our clients to publish some adds on it.
The add is first received and checked internaly by an add editor. Then, we are asking the client for the payement and when the payement is received, the add is published.
My goal is to give the possibility to our clients to pay with their credit card.
For example, send them the invoice by email with the link (or button) to a webpage where they could introduce their CC number et all needed information. This page can be created on our website.
I have read some articles about the onLine payement and sow that there is 2 main possibilities:
Use a third party merchant
Use my own merchant account
Which one of those two solutions are better in your opinion, are ther advantages - disadvantages ?
Is there another solution except those two?
What about the solution to use my own merchant account? Complicated to implement ?
Thank you very much.
Unless you have a lot of resources available to comply with the PCI DSS standards ( https://www.pcisecuritystandards.org/ ), use a third party. Much less hassle.
I'm working on a project where we collect payments from users using credit/debit/PayPal payments.
The service is taking payments from users on behalf of a 3rd party organisation.
Once we take the payment, minus fees, we want to transfer the amount to the organisations bank account.
For now, what we can do is pay the organisation using Online Banking BACS bank transfer.
But I would like to know if there is a way to do this automatically using an API.
If we need to somehow register the 3rd parties bank account details before making transfers, this is fine.
We just want to automate the whole process, since at the moment the transfer is a manual step.
Are there any gateways or APIs I can use for this? In the UK?
As this is still un-answered I'll throw my hat into the ring.
For the benefit of non-UK users, the UK has a central clearing system called Bacs, which is run by the major banks in the country. However, companies can also makes submissions directly to that clearing system, by using Bacs Software.
There are a number of companies that sell on-premise and online services/APIs that allow you to send money directly via Bacs (and collect Direct Debits).
DISCLAIMER: I currently work for a software company (Bottomline Technologies) which sells a Bacs API - I won't mention the product name and to see alternative companies you can simply Google for 'bacs software api'
Hope this helps
You are going in the wrong direction. You should talk to payment processors (which may or may not include your bank) about the business considerations, which probably are more important than the technological considerations. Generally you can expect something somewhat reasonable that you will (after fiddling with it enough) be able to convince to work. It doesn't matter whether this involves some sort of api library, soap calls, or other communication method.
If you honestly consider having the technological considerations more important than the business considerations, then just go with Paypal and don't write your own shopping cart stuff at all. This is easier to use and will do more of the heavy lifting for you, but which will also probably charge you more.
Once you create a real shopping cart and start handling payments yourself (i.e. taking in CC information and sending it to a payment processor), you start getting into a mess of legal and technical concerns involving PCI compliance and the like, which will apply regardless of your choice of payment processor*.
*This is US-specific, but I bet the UK has something similar.