We want to have a SetupIntent and PaymentIntent confirmed at the same time. The reason is that we have a product which is paid yearly (beginning) and also metered billing where the customer pays based on usage each month.
Because of the dual durations (month/year) we have two subscriptions with one subscription item each.
To activate one of them we give the client_secret to the frontend where it is used to send payment data.
How can I use that to activate both the SetupIntent and the PaymentIntent as well without sending the customer both client_secrets and expecting to fill out the card data twice.
Beset regards and nice weekend!
I found a solution, where a proof of concept in the test world worked:
Create a setup intent
Give the secret to the user
As soon as the payment method is accepted, I can create both subscriptions
For knowing WHICH subscriptions to create, I put those data into the metadata field -> Can use this data in the called webhook :)
In the webhook I can then create and directly confirm the subscriptions :)
done!
Sounds reasonable, right?
Related
I'm new to PayPal and its PDT. I've searched through many posts but they require Node.js or PHP to implement it. I don't have both, but I just want a simple return from PayPal PDT, telling my download.html that the purchase was successful so that I can safely display the product key to my customers and allow them to download my digital product, otherwise I will do something like this in my JavaScript:
If (purchaseFailed) {
window.location.replace('/404.html');
}
The reason that I do that is to prevent direct access to my download.html and reveal the product key without making a payment through PayPal.
I've enabled my PayPal PDT and specified the return URL, but I just do not know how to write the JavaScript to get the return the status from PayPal. I do not need to display any transaction detail to my customers except a 'thank you' message, the product key, and the download link (but if you can show some sample on getting the transaction details, e.g. product code and customer email address, that would help too). Can somebody help me with some simple JavaScript that my Google Blogger HTML can execute it? Thanks a lot!
PDT is completely unreliable, because returns are never guaranteed to happen, due to browser/network crashes or the customer not waiting for the auto-return (there is a timer) or not clicking through to return (typically guests w/o an account must be shown a receipt and click to return). So PDT is suitable for informational purposes only (e.g. showing buyers a thank you message when they do return.).
Absolutely no business logic such as downloads should depend on a PDT return actually occurring.
Instead, if you need a dependable notification from PayPal of payment completion, an asynchronous IPN or one of the newer webhooks should be listened for -- or alternatively, the integration should be changed to a more robust synchronous server-side one such as this pattern: https://developer.paypal.com/demo/checkout/#/pattern/server , where there is always an immediate API response on payment capture for notification purposes.
Blogger's HTML/JS does not provide any of the necessary listening or API capabilities, of course.
I try to integrate PayPal into my checkout process. Here is what I did:
I managed to use the Paypal API Node SDK to create payments with PayPal.payment.create.
and then redirecting the user to the payment URL I get in the response to links[1].href which is something like this: "https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_express-checkout&token=EC-00N000849T505604G".
On that page I sing in with my sandbox user and pay the transaction, I get redirected to my custom success page I declared when creating the payment.
On my Success Page, I want now to check if the transaction really was successful to update my database, so I call my backend, that calls a GET to the transaction to the links[0].href which is something like https://api.sandbox.paypal.com/v1/payments/payment/PAY-1VL72645VS000000XLLARPMI to check for the status.
Unfortunately, the state property of the response is always created.
What am I doing wrong? How can I check it? I was using these docs as a reference.
Generally, I’m a bit overwhelmed by the number of docs and not sure which one is correct and could not find any concise tutorial :S
Thanks for your help!
State property of the response is created is the current one.
The state property's possible values created, approved, failed.
created. The transaction was successfully created.
approved. The customer approved the transaction.
failed. The transaction request failed.
but approved. should be The buyer( not customer) approved the transaction.
You can get this from Payment.php file in line #376 of PayPal-PHP-SDK project.
https://github.com/paypal/PayPal-PHP-SDK/blob/master/lib/PayPal/Api/Payment.php
At first State property will created but it will be approved when The buyer approved the transaction using Update payment then you can check List payments /Show payment details then you will found payment is now approved.
For Update payment
https://developer.paypal.com/docs/api/payments/#payment_update
and Show payment details https://developer.paypal.com/docs/api/payments/#payment_get
What are the steps that I need to follow to properly charge a customer using square-connect?
I'm confused because the documentation is not very clear about this.
Do I have to create an Order object then do a Transactions and the Charge?
Do a Transactions and then charge?
Can charge directly?
Generally your workflow is to create a card_nonce using the payment form, and then send that to the charge endpoint with the amount you want to charge.
Create card nonce -> Charge
If you want itemizations for your transaction, you can optionally create an order as well
Create card nonce -> Create Order -> Charge
I'm working on an app that comes with a 14 day trial for free.
To handle payments, I'm using Stripe and listening for webhooks so I can perform functions on the backend when events happen.
One thing I've noticed, though, is that Stripe is sending me invoice data with an amount charged of $0 for the trial period. So, if a customer signs up, they get an invoice from Stripe for $0 (I have my webhook setup to fire off an email for each invoice I receive).
This isn't terrible, but from a UX perspective, I'd like to avoid the shock of getting an immediate invoice when someone is expecting a trial (even if that invoice is for $0).
I've considered just checking the data Stripe sends over and filtering out $0 invoices, but if I offer a discount or something, this doesn't seem like the best way.
Any thoughts/notes on how to implement this better?
A couple options here:
When you create the customer/subscription, the API returns both the customer and the subscription data to you in its response. You can use data from either or both of these to filter intelligently. Of particular interest:
current_period_start: This will also be the timestamp of the invoice.
trial_end: Until this timestamp, any invoice including a subscription is for a trial.
customer: If you don't like the others, you can always query the customer record when processing a $0 invoice. Customers in their trial period have a status of trialing.
If you're sending the email on invoice.created events, only the initial subscription invoice is created as closed. All other subscription invoices are open when Stripe creates them. (This is so you can make adjustments before the invoice is processed.) An invoice that's both $0 and closed has a high probability of being a trial—100%, in fact, if you're not otherwise creating already-closed invoices.
Try to listen for charges events. The event charge.succeeded Only fired when user has ben charge successfully.
How should I design an on-login middleware that checks if the recurring subscription has failed ? I know that Stripe fires events when things happen, and that the best practice is webhooks. The problem is, I can't use webhooks in the current implementation, so I have to check when the user logs in.
The Right Answer:
As you're already aware, webhooks.
I'm not sure what you're doing that webhooks aren't an option in the current implementation: they're just a POST to a publicly-available URL, the same as any end-user request. If you can implement anything else in Node, you can implement webhook support.
Implementing webhooks is not an all-or-nothing proposition; if you only want to track delinquent payments, you only have to implement processing for one webhook event.
The This Has To Work Right Now, Customer Experience Be Damned Answer:
A retrieved Stripe Customer object contains a delinquent field. This field will be set to true if the latest invoice charge has failed.
N.B. This call may take several seconds—sometimes into the double digits—to complete, during which time your site will appear to have ceased functioning to your users. If you have a large userbase or short login sessions, you may also exceed your Stripe API rate limit.
I actually wrote the Stripe support team an email complaining about this issue (the need to loop through every invoice or customer if you're trying to pull out delinquent entries) and it appears that you can actually do this without webhooks or wasteful loops... it's just that the filtering functionality is undocumented. The current documentation shows that you can only modify queries of customers or invoices by count, created (date), and offset... but if you pass in other parameters the Stripe API will actually try to understand the query, so the cURL request:
https://api.stripe.com/v1/invoices?closed=false&count=100&offset=0
will look for only open invoices.... you can also pass a delinquent=true parameter in when looking for delinquent customers. I've only tested this in PHP, so returning delinquent customers looks like this:
Stripe_Customer::all(array(
"delinquent" => true
));
But I believe this should work in Node.js:
stripe.customers.list(
{delinquent:true},
function(err, customers) {
// asynchronously called
});
The big caveat here is that because this filtering is undocumented it could be changed without notice... but given how obvious the approach is, I'd guess that it's pretty safe.