How can I use PayPal to charge users for feature(s) in my MV3 Chrome extension?
I'm specifically looking for PayPal as Stripe isn't supported in my country.
This is the first-ever time I'm trying to charge money for anything, so I wish to do it the right way the first time.
Also, my extension is open-source, so if I could make the code in a certain way to prevent the user from bypassing the storage to enable the feature without paying, it'd be cool.
You need a web server that provides services and payment verification if you want to prevent the user from bypassing anything.
Current versions of the PayPal Checkout require loading external JS resources, which browser extensions typically frown on. So the simplest solution, again, is going to be to have your extension direct over to a web page to handle the payment.
If you insist on processing the payment directly from your extension, the only possible way would be using a legacy HTML-only PayPal flow, most simply opening a tab to a link such as:
https://www.paypal.com/webscr?cmd=_xclick&item_name=payment%20purpose%20goes%20here&amount=100¤cy_code=USD&business=receiverofpayment#emaildomain.com
This would not be at all secure or verifiable, other than perhaps if you were to also integrate the legacy IPN service on a server (also a bad idea).
So in summary, to do what you want to do you ought to pair a server and web page with your extension for payment processing/verification.
See the full stack example at https://developer.paypal.com/docs/subscriptions/integrate/ , and do API calls from your server's backend (in whatever programming environment, the node js there is just an example) for the order creation and capture. Your 2 server routes should be called from your web page, ideally using this approval flow includes a sample of error handling code for if the capture fails.
Related
Background
I am integrating stripe API into my site to take one off payments. My site will be API first on server side with a separate web and mobile front end. I am working on the API server side code. I will eventually use stripe payment pages to take credit card payments. I am trying to automate the testing of my APIs and am bamboozled by the documentation (which are thorough) as I just can't see what steps to take next.
My server side initiates a call with stripe using stripe sdk to create a stripe Session object - this contains a URL to redirect to checkout.stripe.com/pay/..., a success URL when payment is successful and a cancel URL (these I set to handle the callback).
Problem
I can automate in Postman all my API calls from Browse Products, Select Product, Place Order but the next step I am stuck. After Placing Order I get back the stripe session but how can I mimick making the payment with stripe for the session and then call my Success URL ?
When the site is complete I will redirect the UI to stripe to take payments but I am testing and completing the back end flow first.
I have copied and pasted the session URL which is returned by the stripe Session object to bring up the page in a browser and used Dev tools on Chrome to inspect Network to see which APIs are being called by stripe in an attempt to reproduce and I can see a POST to stripe.com/api/payment_methods and I can see the posted values but I can't reproduce this in Postman. Also, the documentation (https://stripe.com/docs/api/payment_methods/create) says
"Instead of creating a PaymentMethod directly, we recommend using the
PaymentsIntents API to accept a payment immediately"
Question
Which stripe APIs do I need to call to automate the flow from a stripe Session object to make a payment and then check that it was successful? Payment Methods? Make a Charge? Payments Intents? ...and how. Happy to be pointed to the documentation if you can help me understand the flow.
TIA
Checkout is a Stripe product that looks like a "box" and you can't know (and shouldn't need to know) what happens inside. It is created for the purpose that merchants won't have to think about what's being done under the hood.
Speaking from an automation perspective, you can try to reproduce the whole process but there's no guarantee it won't change in the future, and it could leave you with more problems later.
For options to reproduce:
The closest way is simulating browser filling and submission, using automated browser tools (ie Selenium). But it's not as straightforward as PostMan. Generally you would want to simulate every browser action that a human could do.
Or you can try to accomplish the same with the logs and events you receive on Stripe's Dashboard, when you test a Checkout Session by yourself. From now there are 3 requests.
And your goal is to receive the same 5 events in Webhook:
TBH I recommend to reconsider the need of this test, to see if it worth your efforts.
Our scenario is the following:
We have an SPA that we package and send to multiple customers.
The customers hosts the SPA on an arbitrary domain like www.unknown.com/spa/anything-goes, or www.also-unknown.com/spa/really-anything-goes, etc.
The customer also opens the SPA in a popup window and injects a service to communicate back and fourth from the popup (the SPA) and the main window.
The SPA uses our own API service, lets call it www.backend.com, as a backend.
The SPA also uses the service that is injected into the popup window by the opener (the customer website), meaning the main popup (where the SPA is loaded) window can't directly redirect to a common login page, because that will interrupt the connection to the injected service, and we can't modify the customer code to make it more robust).
We want to let the user of the SPA authenticate against our backend (www.backend.com) using SSO (their Microsoft credentials)
For any given (fixed) domain, we can make this work by approving the exact domain as an allowed Redirect URI in AzureAd, and just using the MSAL in the SPA.
But how would you go about using SSO when you don't know ahead of time which Redirect URIs to add in AzureAd?
We can't re-direct the SPA to a common login page (cleared in AzureAd), because that would break the connection to the injected service.
The msal-browser library has an option to use a popup window instead of a redirect directly in the SPA window, but this option also needs a pre-approved Redirect URI.
I'm thinking we may need to implement custom logic to let our SPA open a popup window that navigates to a page we can pre-approve as a Redirect URI, that itself has the MSAL library and does the SSO login and communicates the result back to our SPA. But before I attempt a custom solution like that, I wonder if maybe I'm missing something.
Is there a more standard, less "hacky", solution that I have missed?
We would appreciate any input, thanks!
We eventually went with the solution I hinted at in the question:
Publish a simple page including the MSAL library on a "central" location that we can pre-approve in AzureAD. Let's call that the Central SSO-page (CSSO).
Let each SPA, running on what ever domain they want, open a popup with the CSSO. This runs the MSAL and completes the login.
CSSO has logic that, on login-completion, communicates back to the SPA, using window.postMessage("Some message", "https://somerandomdomain.com")
The SPA sets up a listener window.addEventListener("message", handleMessage(){..logic here}).
The drawbacks are, as far as I can tell, mostly that you need to make sure you are posting the message so that only the correct window can receive it.
Another drawback is that popups are often blocked, but in our case that is unlikely since our SPAs are running from domains where the main way of loading our SPAs is through a popup, so for the user to even see our SPA, popups must already be allowed. Still, some fallback logic is needed to open the popup manually with a click (which seems to circumvent the default block of popups).
I'm a newb with Google OAuth and am trying to understand the different business/application models and which API credential types go with my particular situation.
I am creating a Chrome extension for someone for their own private use which accesses their Google Sheets docs using their personal Sheets account. So, I will not own the code or extension once I deliver it to them and end the contract. So, I do not want to have to maintain any authorization/API ID's or credentials after I deliver the extension and its source code. But, obviously, the extension must continue to work for them indefinitely.
The only way I can see how to accomplish this is to instruct the employer (who has no developer or development skills) on how to create the OAuth Client ID with their own Google API developer console. Then, they can enter the client ID and other codes if necessary into the extension config screen so the extension can use this information for authorizing API calls. This seems like a huge hassle for someone who just wants to buy an extension to do something simple.
Am I missing something? Is there an easier way?
P.S. I know this question doesn't follow the proper format for SO, but this is the only place Google has provided for asking API OAuth 2.0 questions.
I would like to know if this is possible to add new payment method for Bigcommerce. I tried to contact their support without any luck. If anyone is familiar with bigcommerce and know if this is possible, i would appreciate any advice.
I already read their API docs and didn't found anything useful - only method to obtain list of available payment methods.
I already tried to signup for their partner. Without any luck.
We've done this before for a couple stores to allow clients to process payments through their own processor. The way we achieved this, is essentially through the following high-level steps:
Allow payments by Check (or similar offline method). We are going to replace this with the custom processor.
You'll notice that if you attempt to checkout via Check, that BigCommerce automatically creates the order for you, but sets the order status to Awaiting Payment. Upon submission the user is automatically sent to a 'Thank You' Order Confirmation page that contains both the Order ID and some payment instructions (such as where to send the check to).
Here's the trick -- Modify this 'Order Thank You' page to prompt the user for her or his credit card information. A simple HTML form will suffice here, performing the actual request via JavaScript.
Once you have the user's credit card data, you can then POST it to your own external server, where you would connect to and send data to whichever processor you are using. Additionally, you should make sure to send the Order ID to this program, so that you can connect to the BigCommerce API to load billing information, and then subsequently adjust the order status to either approved or declined depending on the response from your processor. Finally, you should send back some sort of response to the client to inform of the result of the charge attempt.
That's pretty much it in a nutshell. The way you integrate with the payment processor (step 4) is unique to whichever processor you are using. I hope this makes sense.
Although opinion based, I'm a huge fan of serverless technologies, and would suggest looking into AWS Lambda + AWS API Gateway. The benefit here is that you don't need to worry about creating an infrastructure or the associated concerns of security and scale. Rather, AWS Lambda allows you to simply upload your software, and allows it to be executed via an HTTP request to some defined endpoint set through the API Gateway. Lambda will scale automatically for you, and you don't need to worry about system level security concerns - only security at the application level. It's truly a set and forget setup, and a bleeding edge technology. Not to mention dirt cheap!
Implementing a new payment method is unsupported and requires hacky workarounds since we implement payment gateways via the core app. You can do this on blueprint by using an offline payment method and then using the API to update payment statuses, etc. I'd recommend using ActiveMerchant if you do wish to go down this path.
Is there a way I can create an addin for my Gmail account? Is GreaseMonkey the only real way?
I use Gmail for customer service, and I'd like to create a tool that looks up the customer and preps a response to them based upon who it is in my database... instead of looking by hand for the client and typing it out.
You can add gadgets (same as iGoogle and wave) and add them to the side bar in GMail, but you will not have access to the e-mails themselves. You could create small lookup forms and such, though.
I don't see how else you could do it. You won't be able to run your own app on Google's backend, so that leaves the client (with javascript and something like GreaseMonkey) and your server (perhaps communicating with the client via AJAX).