I'm developing a flutter app, and I've come across different payment solutions such as
squareup payments, paystack and stripe. However all these systems essentially require you to setup an account with their services, then you can only charge money to those accounts.
What I'm looking to do is enable monetary transfers between users on the app, and simply charge a fee on top. What are the best practises for such a system? So a callable api in the vein of Venmo, or Square Cash that I can call from code when I get the details I need.
Should I create my own backend for this? If so what should I use? (I'm primarily working in golang, but I'm flexible)
Or is there a nifty flutter plugin or API gateway that I can just use directly from the mobile client?
There are various services for doing such a thing,
Usually at my firm we would have our .NET rest server get the payment request from the client, and later charging it with some service that is verified for payments at our country.
Note:
You will be needing to associate with that service and there will probably be fees.
Depanding on your country, you most probably MUST NOT store the payment data on your own server unless you have a certificate for doing such a thing (security standerts etc.)
If this is a private project I would suggest researching about migrating with PayPal since you won't need to handle security and the payment would go through them.
May be helpful: paypal developers
Related
I have a native mobile app in which I want users to subscribe for a monthly fee. I started by integrating with the native PayPal SDKs and use future payments, but in that case I'm in charge of processing the payments every month. I want a more automatic way where users approve their subscription and PayPal automatically posts the payments every month.
I have also started looking at Stripe, so if there is a solution using another library I would be glad to hear of that too.
(Disclaimer: I work for Stripe.)
Stripe does support recurring payments with the "subscriptions" feature. You can read more about it here:
https://stripe.com/docs/subscriptions
https://stripe.com/docs/guides/subscriptions
To implement this in a mobile app, you'd need to use the iOS SDK and/or the Android SDK. Both SDKs offer the same functionality: the ability to turn card information into a token, by exchanging the information directly between the user's device and Stripe's servers.
This way, the sensitive card information never hits your server, which greatly reduces the burden of PCI compliance. You can read more here: https://support.stripe.com/questions/do-i-need-to-be-pci-compliant-what-do-i-have-to-do. (This article talks about Stripe.js and Checkout, but the mobile SDKs serve the same purpose.)
Once a token has been created, you'd need to send it to an external server, where you would use it to create a customer object and a subscription, as explained in the subscriptions documentation I linked above.
The reason why this needs to be done on an external server and not in the app itself is because aside from the creation of card tokens, all other API requests need to be sent with your secret API key. You cannot embed or otherwise provide the secret API key to your app, as an attacker could extract it and use it for malicious purposes (they could refund past charges, use your account to test stolen card numbers, etc.).
So this question isn't about integrating an existing payment gateway into my site. This is more of a architectural question.
I want to build a system similar to Paypal. Now I understand that Paypal offers a lot of features under the roof and I can't implement all of them at once. I want to implement the core functionality of Paypal and other such services.
So my question is (rather discussion is) around how would one go about building such a system. Some points to discuss:
Allow users to securely store and process their payments
How does Paypal handle the transactions?
Handle payments through existing banks. I am guessing that I would need access to local bank protocols to get this.
Where I can find documentation of paypal or any other payment gateway to get the idea of its core functionality
Thoughts?
If you want to directly integrate with banks, you want to become a payment processor. This is quite hard to achieve (especially on the compliance side) and the market is dominated by a few giants (First Data Corp., Total System Services Inc. (TSYS), Vantiv Inc., Global Payments Inc. and Heartland Payment Systems Inc.).
A payment gateway however is a system that accepts card payments, and offers value added services such as recurring payments. Gateways (unless they are a processor themselves) most often delegate the actual processing of the cards to a payment processor.
Becoming a gateway is easier and you can even partner with ISOs which will provide you with white-labeled solutions (e.g. Intrix). You can also take a look at Kill Bill for an example of an open-source payment gateway.
Regarding security, if you want to minimize PCI compliance, you can delegate the actual storage of the card to online vaults.
I have looked at the Paypal REST API and at classic API. I like the Direct card processing support the REST API offers and the ability to use the Vault from the REST API.
Only problem is our PayPal sales rep insists the REST APIs are not stable and should not be used and wants us to use PayPal payments Pro with this Class API .
We have a business account and only expect to receive payments in the US, which per this link should be supported just fine. We need to accept payments using a mobile app and website. The mobile app needs to support one time transactions and both (app and website) need to support transactions using stored credit card information (which is where the Vault feature seems really handy).
I clearly see a lot of REST API questions so now doubt its in use.
Question for devs using the REST API over the past 6 months:
has it changed in a breaking manner for you?
Is it reasonably available (99.9%) for your applications?
Does using the Vault REST API feature require a Payments Pro account?
The RESTful APIs would work for you based off of what you stated. Granted they are not to parity with the Classic APIs just yet but the features you were requesting (Direct Card and Vault) are good to go. Pro is not required for Vault with a US account.
Lastly, without knowing the full conversation you had with your Sales Rep, I can't comment on why they felt so strongly against the RESTful APIs. However, if you open up a ticket at www.paypal.com/mts with all of your integration requirements, we can help you out with the best options available.
I have an iPhone app where I have a list of items to be sold. For the payment of these items, I have a web service on my sponsor's server that needs to be utilized by sending certain parameters such as amount, userid, discount coupons etc. So should I invoke this in a web view inside the application or should it be invoked in the web-browser? The sponsorer wants to show a message as payment successful or not in the application after everything is done. this information comes from the server itself. But if I invoke the browser i will not be able to track this information about payment successful or not? What should I do? Please help me with this
This is particularly interesting with regards to iOS as it gives app developers a fairly easy way to implement an alternative payment solution to the App Store, something that doesn’t infringe on Apple’s in-app purchasing policy if the goods being sold are physical not digital. It’s this scenario that Adyen is targeting.
As for the payment method itself, it accepts credit cards, PayPal and a range of other payments within mobile applications (native apps) and mobile websites. Of course, offering a HTML (browser-based) version of an app or service rather than a dedicated iOS app is another way of bypassing Apple’s cut.
Other benefits of Adyen’s payment platform is that merchants and developers can take advantage of a “fully integrated service that removes the burden of security and PCI compliance”, says the company. In addition, app developers can “skin” the mobile payment and checkout process, gaining control of the look and feel, which is said to be an important driver for increased conversion rates.
Merchants already using the new mobile payment platform include Pathe, the largest chain of cinemas in the Europe, via its iPhone app, and Greetz, the online greetings card retailer.
I am developing one application which has use of physical ordering like restaurant food ordering.
Now i am stuck on how will i use the payment Gateway in which i heard from many sites after searching on google that Apple is rejecting the application if I don't want to use the InApp Purchage as it does not support for physical goods.
I don't want to use Paypal and google checkout because it is more expensive as per my client business.
Client uses the website already for their business in which he used the third party payment gateway from www.fatcow.com which use the service of authorize.net
1) I got another option that i can open website mobile pages in Webview and handle it from their but still confuse if apple will reject the app.So please tell me how should i use the 3rd party payment gateway to place my order ?.
2) How can i successful make transaction and credit card processing in application is there any API or something available please provide some information.
Any help will be appreciated .
Thank You.
To my knowledge you should not use any 3rd party payment gateways to process any debit/card transactions until unless its solely meets ISO 8583/8587 protocols and PCI (Payment Card Industries) standards. Any kind of hacky way, will put you in trouble.
nProb,you can use your existing support to make transactions but change you want to made is ask the web team to give you some API's which will carry the transaction process ,
For example , Web Team give a web service - contains all parameters [cost,creditcard etc] ,
then you pass these values from your app with form ui , the the web service will perform transaction & make to return status to your app by json or xml to intimate users that it is a successfull transaction.
Apple will never reject your app , as we have approved 5 similiar payment based apps.
Hope this helps!