why do developers use Stripe not Master-card API or Visa API while stripe charges money more. i checked and found out Master-card and Visa have their own API's , i guess there's something there i don't understand? probably i live in egypt, which global service should i use to integrate in my PHP websites while Stripe is not available in egypt?
sjsonp1389885476573({
"error": {
"message": "Your card was declined.",
"type": "card_error",
"code": "card_declined"
}
}
, 402)
Thank you
One of the primary reason why developers use payment gateways such as stripe and not separate APIs for master, visa, maestro etc. as you need to do development and testing individually for these APIs along with monitoring any changes that happen with them.
Stripe on the other hand provides an API layer over all these APIs and simplify them so that businesses don't have to worry about integrating the separate APIs.
The list of payment gateways available in Egypt currently includes :
2Checkout
BitPay
Coinbase
GoCoin
Mastercard Payment Gateway Services
NETbilling
PayFort
PayPal Express Checkout
Paystack
Also, the integration time is very less with these payment gateways as compared to the APIs of payment solutions such as master, visa, maestro, etc. as these gateways provides single API which supports payment options for all major payment solutions.
Hope this helps!
Related
I see paypal is upgrading their APIs. I want to collect recurring payments and provide a feature to upgrade / downgrade the plans.
In the samples, paypal is using billing agreements and when I see the docs, it says the API is deprecated please use subscriptions API. I am confused which one to use.
Please help me in this.
PS: Also my product includes one time payments
The PayPal Subscriptions API uses billing agreements and plans, and there are multiple versions. Everything linked from https://developer.paypal.com/docs/subscriptions/integrate/ will be the most recent version.
For one-time (non-subscription) payments, the most robust integration is to have two routes on your server that implement v2/checkout/orders API calls to "create order" and "capture order", combined with this front end: https://developer.paypal.com/demo/checkout/#/pattern/server
For a subscription integration to be similarly robust (in that your server gets an immediate API response of profile activation), you can have those buttons call your server as well: PayPal Smart Subscribe server side
I am currently developing a marketplace type of website. When it comes to handling payments, I would like to be able to charge customers on behalf of sellers.
Which payment gateway API should I use (if this is even possible)? I am using React and Node.
For reference, what I was looking for was something like Stripe Connect. According to their website: "Marketplaces and platforms use Stripe Connect to accept money and pay out to third parties. Connect provides a complete set of building blocks to support virtually any business model, including on-demand businesses, e‑commerce, crowdfunding, and travel and events."
I saw that Google released a new Google Pay API for the web. However, there is also a Payment Request API fo the web. Is Google Pay just a rebrand of Payment Request API? In what cases would you use one API over the other?
The "Payment Request API" is a W3C standard and a part of "Web Payments" effort. This means the API is expected to be implemented by multiple browsers and it's already landed in Chrome, Edge and Samsung Browser. And it's also expected to be available on Firefox, Safari and so on. Payment Request API is never a Google's property and it's an open standard.
https://www.w3.org/Payments/WG/
The Payment Request API is said to allow users to pick their saved credit card information with just one tap. But it's just a part of larger ecosystem. It can integrate with any third party payment apps and allow users to make payment through those apps via the Payment Request API.
Consider Google Pay one of such payment apps. Other good examples are upcoming Apple Pay (when Safari implements the Payment Request API) or Samsung Pay. Alipay also implemented one and have done a talk about it at Google I/O 2017.
https://www.youtube.com/watch?v=hU89pPBmhds
What makes it look complicated about Google Pay for those who knew about the Payment Request API is that it conceals the Payment Request API behind its library. By initiating Payment Request with just a single payment method without requesting shipping information, you can bypass Payment Request user interface and directly launch the payment app (in this case Google Pay).
https://developers.google.com/payments/web/tutorial
This article should be a good start:
https://medium.com/dev-channel/addressing-common-misconceptions-about-the-payment-request-api-4d0db51dae75
Hope this helps.
How to create a WEBSERVICE for CreditCard payment processing in C#.NET?
I want to process electronic payments. I am currently using PayPal but it costs too much. Many companies are able to provide electronic payments without using gateways. I imagine they use banks web service directly.
I think you have to implement interface for each gateway: Authorize.net, SkipJack, Moneris, Mrw etc. Some of them give you a DLL to use their gateway or provide documentation how to make requests to API. Otherwise I think you need to implement interface for each bank you want to receive payment..
I have a client who has content that he wants to publish on the web (and potentially for iPad). He wants the viewer to pay to subscribe for the content.
Is there a service out there I can integrate with to for handling the accounts and collecting the monthly subscription fee (using credit cards or something else)?
There are several services out there that can help you with this - Recurly (where I work), Chargify, CheddarGetter, Spreedly, etc. These services handle the recurring billing aspect, customer management, email communication, following up with failed payments, etc. You'll also need a payment gateway (to process the cards) and a merchant account (for the payment gateway to deposit the funds into).
Authorize.net and PayPal both have recurring billing features, but the logic for upgrading/downgrading accounts is not there or difficult to use, and you'll still need to handle customer communication for failed payments and other actions.
You need to use a payment gateway here, which will be responsible for handling the transaction between your site and the many different payment networks. There are a lot of operations happening in between, so you might want to check out the wikipedia article for a step by step information on that.
We personally use authorize.net in our company for many of its advantages, some of which are:
It has an API that makes it easy to integrate with any language.
It is a trusted brand already, proven by the number of merchants that use them.
It is secure.
It provides the service with a reasonable price.
Most of major payment gateway providers do support recurring billing or subscription plans, paypal,authorize.net etc, most of the time you have to log in to your account admin console and configure a plan, and send the payment plan id with the payment request to the payment gateway. some payment gateway providers, like Braintree supports to create recurring billing plans dynamically and assign users to that plan at the run time it self, how ever it's always better to go for a local payment gateway provider or a payment gateway which provides low fees, if your preferred payment gateway provider is not supporting recurring billing anther options is to store cc details on the server and and handle it your self but it's a great risk to store cc details on the server, and you will have to follow PCI standards and it's hard.