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?
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.
Doing some research on Shopify, to determine if I want to use it.
So, I bought something from a site that uses it, and looked at the view source at each step
I was horrified to see that in the Javascript returned with the checkout receipt, their is a horrifying amount of credit card info easily viewed and therefore easily captured by a hacker.
Here is a sample with all my data changed
<script>
Shopify.checkout = {"created_at":"2019-11-13T19:57:17- 05:00","currency":"USD","customer_id":1234566541236,"customer_locale":"en","email":"zippy#hotmail.com"," location_id":null,"order_id":1870404943944,"payment_due":"114.33","payment_url":"https:\/\/elb.deposit.s hopifycs.com\/sessions","phone":null,"presentment_currency":"USD","reservation_time":null,"reservation_time_left":0,"requires_shipping":true,"source_name":"checkout_next","source_identifier":null,"source_url":null,"subtotal_price":"99.00","taxes_included":false,"tax_exempt":false,"tax_lines": [{"price":"6.41","rate":0.06,"title":"OR State Tax"},
{"price":"1.07","rate":0.01,"title":"Oregon Tax"}],
"token":"4c9d55f9bb8898e40fe36e1e75988070",
"total_price":"114.33",
"total_tax":"7.48",
"updated_at":"2019-11-13T19:57:40-05:00",
"line_items": [{"id":"0d2b6dd0ad0186984480fb36817f9ed8","key":"0d2b6dd0ad0186984480fb36817f9ed8","product_id":15925165 42536,"variant_id":15850525491272,"sku":"ESI 071252","vendor":"My Shopify Store","title":" Euro High Flow S1 Male Coupler","variant_title":"3\/8\" Male","image_url":"https:\/\/cdn.shopify.com\/s\/files\/1\/1239\/9256\/products\/DSC01397.jpg? v=1549034841","taxable":true,"requires_shipping":true,"gift_card":false,"price":"24.75","compare_at_pric e":null,"line_price":"49.50","properties": {},
"quantity":2,"grams":85,"fulfillment_service":"manual","applied_discounts":[]},
{"id":"062af9384331b020660f9a021afb55ed","key":"062af9384331b020660f9a021afb55ed","product_id":142986457 9144,"variant_id":12867363536968,"sku":"ESI 071202","vendor":"My Shopify Store","title":" Euro High Flow S1 Female Coupler","variant_title":"3\/8\" Female","image_url":"https:\/\/cdn.shopify.com\/s\/files\/1\/1239\/9256\/products\/0U9A6198.jpg? v=1568991566","taxable":true,"requires_shipping":true,"gift_card":false,"price":"24.75","compare_at_pric e":null,"line_price":"49.50","properties":{},
"quantity":2,"grams":85,"fulfillment_service":"manual","applied_discounts":[]}],
"gift_cards":[],
"shipping_rate":{"handle":"BOXIFY (2.0)-USPS%20Priority%20Mail%7CC7739467-7.85","price":"7.85","title":"USPS Priority Mail"},
"shipping_address": {"id":1234566543458,"first_name":"Tim","last_name":"Simmons","phone":"+15555555555","company":"","address1":"123 Main Street","address2":"","city":"Juxnus","province":"Oregon","province_code":"OR","country":"United States","country_code":"US","zip":"12345"},
**"credit_card": {"first_name":"Tim","last_name":"Simmons","first_digits":"123456","last_digits":"9876","brand":"american_express","expiry_month":1,"expiry_year":2085,
"customer_id":1234566541236},
"billing_address": {"id":1234566543458,"first_name":"Tim","last_name":"Simmons","phone":"+19148260061","company":"","address1":"123 Main Street","address2":"","city":"Juxnus","province":"Oregon","province_code":"OR","country":"United States","country_code":"US","zip":"12345"},**
"discount":null};
</script>
Is this standard behavior? Showing 10 digits of the CC, mobile number, the expiration info and billing address?
If someone from Shopify monitors SO
PLEASE respond if this is standard behavior or a developer error, I certainly hope its the latter!
A hacker can steal any information if the site has a security hole like some sort of XSS attack.
But the same applies for your online banking, so that's why there are security measures to prevent that.
That said Shopify has a very secure checkout flow, since it's redirecting to a new checkout every time and it's very hard to create a working XSS or CSRF attack. ( not impossible, but a lot harder then a WooCommerce checkout for example )
In addition the Checkout is a closed platform, no APPs ( they will have support for this soon ) are allowed there and only Shopify Plus members can actually edit the checkout.liquid file.
There is no difference if the card details are stored in a input field or in a JS object, if a hacker can get to the object he will be able to get to the inputs as well.
In addition Shopify is very active in the Whitehat Hacker Community any reported bug is paid for https://hackerone.com/shopify and they are quick to fix them.
There is a reason why Shopify is the preferred E-Commerce solution. From security point of view it's a lot safer then a lot of other self hosted services like Magento/WooCommerce.
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.
While trying to test local currency payment I see this error on javascript pay dialog callback:
{"error_code":1383003,"error_message":"Account id missing. sender: 235265828 receiver: 0"}
In facebook dialog I see this:
Sorry, but we're having trouble processing your payment. You have not been charged for this transaction. Please try again.
og:product object is correct (tested by Facebook Object Debugger), payments enabled, company for payments registered and selected, realtime updates script also selected and working.
I have no any ideas what to do. I found only one similar question with solution to set company for payments. And I tried to test payment by different users with different roles (developer, testers, administrators). Also in facebook error list I saw meager description for error 1383003:
1383003 - PaymentFailure - Processor decline.
It sounds like you don't have a company setup. That will definitely cause this error, try adding a tax ID in the company and see if you still get this issue.