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.
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.
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 
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
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.
@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.
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.
@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.
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.