payments gateway

Solar2D General Questions/Discussion
#1

Hi all,

Anyone implemented payments inside an app? not in-app purchases. I’m talking about inserting credit cards or paypal payments. I think I could implement a webview to process the cards or use the plugins that corona have, but I’ve questions about it.

it will bypass the 30% apple/google fee? it will not give problems in google or apple store?

if you already done this, what method did you used? and why?

what will be the challenges i will me dealing with?

Regards,

Carlos.

PS:

I’m going to do a business app with a list of people that have certain skills, if you want to get advice from any of those people you will need to pay for a fee. The payment will be only after the appointment by the person that gave the advice. My idea is: the client insert his/her credit card number before the appointment or in the client area. when he/she books the consultation will be charged. another way is only to be charged after the appointment. for that I need to send the card to a database and the person that gave the consultation in a backoffice will click a button to complete the transition. I think the most secure thing to do is to use a gateway without sending the credit cards from the app to a backend. but I don’t want the client to pay in advance. don’t know if there is a gateway to permit this (only to charge after a certain condition)

I’m going to do a business app with a list of people that have certain skills, if you want to get advice from any of those people you will need to pay for a fee. The payment will be only after the appointment by the person that gave the advice. My idea is for the client puts his/her credit card number before the appointment or in the client area. when he/she books the consultation will be charged.

#2

Yes, it will bypass Apple and Google’s 30% fee. If you set it up correctly, then no, neither Apple or Google will have a problem with it. There are numerous apps that function like this.

Both companies have strict rules on what payments can be made outside of their stores payment systems. I don’t remember the specifics, but I think the key issue was that the service must not be “in the app” or rather “the app itself”. Think of Uber or food delivery companies. Their apps are only a platform through which the user purchases the real world services.

There’s a lot of security and other concerns with such implementations though, so be careful and expect a lot of work and testing.

#3

Don’t process a card input form yourself, and definitely don’t store card details in a database. These days there are all sorts of PCI-DSS and GDPR issues that you need to consider when doing this. It’ll mean that you’re a data controller and you’ll need regulating to ensure compliance. Honestly, just don’t do it.

#4

Indeed. I cant agree enough with Richard when I say that developing your own system to handle, store and/or process credit card information is a daunting task and something that solo developer should never touch. There are too many rules and regulations to abide by and too many risks to make it worthwhile.

#5

thank you both for the reply, so my options are paypal plugin or stripe plugin?

can’t i save the credit card only in the device? with some sort of encryption?

#6

If I choose stripe or paypal plugin, there is a key involved and usually that key is in lua code. How insecure it is to let that key in lua code?

Do I need to store the key in a remote database? sending the key over network.request over ssl with b64 encode will be enough?

#7

I have no idea how the PayPal or Stripe plugins work. You should try asking the plugin developers.

Also, when it comes to transferring financial data, you really need to be careful. b64 encode/decode, for instance, isn’t any kind of protection, it is just a means of formatting data so that it can be safely transported via URLs, i.e. get rid of any “risky characters” during the transfer.

#8

I’ve not worked with those plugins either I’m afraid, but to answer a little more generically - if your code handles the card data in any way at all, you need to comply with PCI-DSS regulations and be audited at least annually, and you’ll be subject to certain GDPR regulations too. In a nutshell, because the customer is giving you, or your code, their bank account details, it’s down to you to prove that you and your code can be trusted to handle that data. Even if it never leaves the customers device, without proper auditing nobody other than you can know that.

When you use the Google/Apple store for payments, you’re leaving it to Google/Apple to prove compliance. They’re the data controller rather than you and your app never actually receives those account details so you don’t need regulating.

Some payment gateways offer different integration methods. Again this is speaking more generically and I can’t advise on Corona plugins here, but with PayPal for example, you can either use their API which means taking the customers card details and pushing through various API calls to create the payment request, requiring you to be a controller, or you can forward the customer on to a PayPal hosted payment form where they enter the payment details themselves, completely outside of your application, and behind the scenes PayPal just sends you back a status code that you can use to determine whether that payment was successful or not, and what to give the user in response. This approach doesn’t make you a controller and doesn’t require you to be audited unless your merchant bank asks for you to be, which doesn’t generally happen unless you’re receiving large amounts of money.

My company specialises in e-commerce. We’ve integrated all sorts of gateways into all sorts of systems, we’ve built bespoke online ordering platforms, we’re partnered with one of the biggest payment gateways, we run PCI-DSS compliant hosting servers, and we’ve worked with a number of fairly large clients to get them or their websites PCI-DSS compliant. Not to blow my own trumpet but I’m more comfortable than most with these things, and even I don’t integrate payment forms directly any more. It just doesn’t make sense to - the penalties for messing up are horrific and just best avoided, even when you know what you’re doing.

Ref taking payment “later” - some gateways offer deffered payments, which is where the banks talk to each other and approve the transaction but the money is then locked instead of immediately transferring. Later on, you push a request to the gateway to complete the transaction and it’s then moved over, otherwise after X days it’s just unlocked again and appears back in the customers account. This is likely what you’re looking for and there should be a gateway that lets you do it without needing to store card details yourself and create the transaction manually. I’ve no idea whether any of the Corona plugins are for gateways that offer this though, sorry.

#9

stripe plugin for example, in iOS version, have a form already. I don’t need to create or handle any form. The plugin take care of that. I just need to put the card number in the form created by the plugin, i don’t know what the plugin does with that number. I know that the money will go to my account.

that means that the plugin owner need to comply with the PCI-DSS regulation, correct? or even Corona, since the plugin is in corona server?

I guess I will dismiss the plugins for security reasons, since they use the API and that means I will be the controller. We will redirect to a PayPal hosted payment form like you suggested. Thanks for the tips :slight_smile:

#10

When you use the Stripe plugin, nothing passes through our servers. I doubt the plugin developer is having any data pass through any servers. I believe it’s just a Lua plugin using Stripe’s REST API’s, so the connectivity is likely at that point just between you and Stripe.

Rob

#11

Rob, “doubt”, and “believe” counts zero to PCI-DSS regulation. If the plugin is not certified from some legal organization, We can’t use it. Stripe plugin for android, I need to do my own textfields, that’s not a problem for me or for anyone, but the

 PCI-DSS regulation can’t approve with “believes”. If the plugin uses REST API the owner of the plugin is the controller so he needs to be regulated and approved. If I make the textfields I’m the controller also so I need to comply with the rules. That’s what i’m interpreting from richard11 advice.

#12

@carolscosta, please understand that my use of “doubt” and “believe” come from the fact that I didn’t make the plugin, nor did any one at Corona Labs. So we can’t speak in certainty with how it works. You would need to talk to the plugin developer to get specifics on your questions. I’m just sharing what I know about the plugin from when the plugin author was talking about it and getting it working.  My knowledge is 2nd hand at best. The best way to find out about its feasibility is to reach out to the author. 

#13

In your original post you mentioned using a webview. If you don’t want to use the IAP mechanic of the app store for processing payments, I’d advise going with that web view approach. Build a checkout process that forwards the user on to a PayPal hosted payment page, or that uses something like Sagepay Inframe to keep the user on your page without the payment actually passing through you. Then just load your checkout in as a webview and pass flags between your checkout process and the app that loads it, to determine when payment is made.

Note though that all gateways take some kind of a cut so although you’ll be bypassing the 30% fee that the app store charges, you’ll still be subject to some kind of a fee. Your merchant bank likely won’t be free either. PayPal is a gateway and merchant all-in-one and doesn’t charge a monthly fee so unless you’re expecting a large number of transactions, it’s probably your cheapest option at about 3.4%.

BUT, many, many mobile users will be cautious about making a payment through an app without the familiar IAP mechanic popping up. Replacing the 30% fee with a 3.4% fee might sound golden, but if you lose 10% of customers because they don’t feel comfortable with being routed to an unfamiliar checkout process, you’re not actually making any more money. At this point you’ve then just given yourself more development work and gained nothing for it.

In a nutshell, that 30% fee isn’t so unjustified really.

#14

@Rob, I understand your point. I can’t use a plugin without any certification and checking the owner plugin webpage he just says it uses the API from stripe. I doubt hes certified to make one Your right, only talking to him, i can have 100% sure about it.

@richard11, millions of persons use apps like uber, airbnb, booking, that don’t use the IAP mechanic of the app store. They are big enough to people trust their card, that’s true, but they didn’t start big. That’s a think I will tell the client to be aware of.

The similar apps I checked  in apple/google store, they all asked the credit card number. zero have the IAP method. That’s why I asked about this methods and the problems I will encounter.

#15

Fair enough. I suppose my point on payments outside of the IAP mechanic is subject to the type of app you’re creating. Apps that incur a dynamically calculated fee, such as for parking, do always use their own checkout and I’ve never felt worried when paying through those.

#16

Yes, it will bypass Apple and Google’s 30% fee. If you set it up correctly, then no, neither Apple or Google will have a problem with it. There are numerous apps that function like this.

Both companies have strict rules on what payments can be made outside of their stores payment systems. I don’t remember the specifics, but I think the key issue was that the service must not be “in the app” or rather “the app itself”. Think of Uber or food delivery companies. Their apps are only a platform through which the user purchases the real world services.

There’s a lot of security and other concerns with such implementations though, so be careful and expect a lot of work and testing.

#17

Don’t process a card input form yourself, and definitely don’t store card details in a database. These days there are all sorts of PCI-DSS and GDPR issues that you need to consider when doing this. It’ll mean that you’re a data controller and you’ll need regulating to ensure compliance. Honestly, just don’t do it.

#18

Indeed. I cant agree enough with Richard when I say that developing your own system to handle, store and/or process credit card information is a daunting task and something that solo developer should never touch. There are too many rules and regulations to abide by and too many risks to make it worthwhile.

#19

thank you both for the reply, so my options are paypal plugin or stripe plugin?

can’t i save the credit card only in the device? with some sort of encryption?

#20

If I choose stripe or paypal plugin, there is a key involved and usually that key is in lua code. How insecure it is to let that key in lua code?

Do I need to store the key in a remote database? sending the key over network.request over ssl with b64 encode will be enough?