How do I check Stripe coupon validity in Stripe elements? - javascript

I'm trying to check coupon validity while using a stripe elements form on the client side without going to server. The idea is that I want to tell a customer if their coupon is valid or invalid before signing them up for something.
Ideally I would be able to just do something like this:
stripe.coupons.retrieve(coupon).then((stripe_coupon)=> {
createToken(additionalData);
}).catch((error) => {
throwCardError("Invalid coupon, please try again.");
});
The issue is that stripe.coupons is not a part of the elements API, it's only part of the server-side API.
The reason I'm hesitant to check on the server side is because I use firestore to store all my data. So that means in order to get this to work, I would have to first write the coupon to firebase, have a cloud function that calls the stripe API to check the coupon validity and then writes that to a separate part of the database just for that, and then set up a listener on the client side that listens for changes to that part of the database to check coupon validity, and all of that would be really slow.
Is there any way to check the validity of a stripe coupon client side in stripe elements?

There is no function within Elements to check the validity of a coupon (you can see all available methods for Stripe.js / Elements here).
If you're using Firebase, what you can do here is setup an endpoint using a HTTP function, in your client-side code make a request to this endpoint using fetch, passing the coupon id you wish to check.
When this request hits this endpoint you will make a call out to the Stripe API to attempt to retrieve the coupon, returning the result to the user; there's no need to store a copy of the coupon within your Firebase database.

Related

How to Capture paypal_fee in Paypal Smart Button/JS SDK (Laravel 8)

I want to retrieve the paypal_fee when paying an order using PayPal smart buttons/ Javascript SDK .
PayPal Smart Payment Button
This is to compute the order net income before saving it in my database. I want to know how to retrieve the value of paypal_fee in every order and store it in a variable.
The JS SDK actions.order.create / actions.order.capture are for very simple use cases. If you are going to do anything automated with the order information after capture, including saving it to a database, create and capture the order from a server.
Use the v2/checkout/orders API and make two routes (url paths) on your server, one for 'Create Order' and one for 'Capture Order'. You could use one of the (recently deprecated) Checkout-*-SDKs for the routes' API calls to PayPal, or your own HTTPS implementation of first getting an access token and then doing the call. Both of these routes should return/output only JSON data (no HTML or text). Inside the 2nd route, when the capture API is successful you should verify the amount was correct and store its resulting payment details in your database (particularly purchase_units[0].payments.captures[0].id, which is the PayPal transaction ID) and perform any necessary business logic (such as reserving product or sending an email) immediately before forwarding return JSON to the frontend caller. In the event of an error forward the JSON details of it as well, since the frontend must handle such cases.
Pair those 2 routes with this frontend approval flow: https://developer.paypal.com/demo/checkout/#/pattern/server . (If you need to send any additional data from the client to the server, such as an items array or selected options, add a body parameter to the fetch with a value that is a JSON string or object)

Stripe - Refund Checkout Session

I’m trying to implement a method for my connected account owners to be able to refund charges collected via a Stripe Checkout Session.
In order to do so, I want to use the following code:
const refund = await stripe.refunds.create({
payment_intent: pi_id,
});
In order to obtain the payment_intent_id, I am listening to the checkout.session.completed webhook, and accessing data.object.payment_intent.
When I attempt to create a refund using this payment intent id, I get the No such paymentintent error from Stripe. I noticed in my Stripe test account that there is a charge ID associated with the payment, so maybe I should be using that - but I’m not sure how to retrieve that programmatically from the checkout session.
You're making the API call correctly.
“No such...” errors with Stripe are usually caused by either a mismatch in API keys (e.g. using a mixture of your test plus live keys) or by trying to access objects that exist on a different account (e.g. trying to perform an operation from your platform account on an object that was created on a connected account).

Gigya - complete registration for an auto-generated account

Newbie to gigya. I have been trying to identify how can I achieve complete registration in my web application for an account that is generated using gigya REST api with an auto-generated details. I have the UID for that account, using which I can retrieve the user details.
My questions are:
Is it possible to complete the registration for that account(auto-generated) using the Complete Registration screen set?
If so, how can I achieve the profile completion?
Screen-Sets are client-side, so, there is no way to use the Complete Registration screen inside a REST implementation.
Three possible solutions are:
If you have the data: Include all the necessary data properties in the call to accounts.register.
If you have the data: After registering the user, using the UID call accounts.setAccountInfo and add the necessary data properties.
If you don't have the data: Don't do anything via REST to complete the registration info (and leave it in 'Pending' state setting finalizeRegistration: false in the accounts.register call. This will cause the API to return "errorCode": 206001, "errorMessage": "Account Pending Registration"). Then add the screen-sets to your page/app and when the user attempts to login, any required information that is missing will need to be provided via the Complete Registration screen, which will automatically fire and prompt the user for this data and then finalize the registration.
#sadiqmc could you explain a little bit about what you're trying to do? What's the flow that you're trying to accomplish?
Edit:
As per your flow, you probably shouldn't use the Update Profile screen to let the user change their info, as the auto-generated content will be pre populated and will confuse the user.
Since you already have the UID, you can build a generic form to collect the user's data and then update the account using setAccountInfo.

Handling successful payment processing but database update failure

I am trying to implement a stripe checkout process in one of my express.js routes. To do this, I have:
Official Node.js Stripe module
Official client-side Stripe module
A json logger I use to log things like javascript errors, incoming requests and responses from external services like stripe, mongodb, etc…
An Order model defined using mongoose - a MongoDB ODM
My steps are as follows:
Client:
Submit order details which include a stripe payment token
Server:
Create an unpaid order and save to database (order.status is created)
Use stripe client to charge user's credit/debit card
Update order and save to database (order.status is accepted or failed depending on response from Stripe)
Question: If payment is successful after step 2 but an error occurs updating the order in step 3 (due to database server error, outage or similar), what are some appropriate ways to handle this failure scenario and potentially recover from it?
With payment systems, you always need a consolidation process (hourly, daily, monthly) based on sane accounting principles that will check that every money flow is matched.
In your case, I suggest that every external async call logs the sent parameters and the received response. If you do not have a response within a certain time, you know that something has gone wrong on the external system (Stripe, in your case) or on the way back from the external system (you mention a database failure on your side)
Basically, for each async "transaction" that you spawn, you know when you start it and have to decide of a reasonable amount of time before it ends. Thus you have an expected_end_ts in the database.
If you have not received an answer after expected_end_ts, you know that something is wrong. Then you could ask for the status to Stripe or another PSP. Hopefully the API will give you a sane answer as to whether the payment went through or not.
Also note that you should add a step between 1. and 2 : re-read the database. You want to make sure that every payment request you make is really in the database, stored exactly as you are going to send it.

Meteor forgotPassword & sendResetPasswordEmail dataflow

I'm not fully understanding the process for processing a 'forgot password' request from the user. Just looking for a little clarification.
On the client you take the user's email and pass that to Accounts.forgotPassword which triggers a call to Accounts.sendResetPasswordEmail on the server. Accounts.forgotPassword only takes email as an argument.
So Accounts.sendResetPasswordEmail is triggered which actually sends the email to the user, but that's looking for a userId...
Just confused by the logic there. Why not just call sendResetPasswordEmail from the client with an email and a userId as arguments?
It's important to note that Accounts.sendResetPasswordEmail can only be called from the server, and is automatically called for you as the result of the call to Accounts.forgotPassword. So in general you don't need to directly call it, however you probably do want to customize the email (from, subject, body) via Accounts.emailTemplates.
Of course, you could call Accounts.sendResetPasswordEmail via a method but consider the most common use case:
I'm a user of the system, but I'm not logged in (no Meteor.userId()). I have an email which is attached to my account. I want to get a reset password email based only on that information. And that's exactly what Accounts.forgotPassword does for you. How convenient!
Note also that by requiring an email on a route that has to be exposed to the public, you are also inherently filtering out baddies which don't know the emails of your users.

Categories