whe created shipping rules, because we have to have to exclude shipping to isles for some products and/or some shipping methods. therefore we used the built-in shipping address: postal code option.
Problem is, when someone is not logged in yet, they dont get any shipping methods that use a postal code rule. so they get the message
"%oldShippingMethodName%" shipping is not available for your current cart, the shipping was changed to "%newShippingMethodName%".
After login or adding the address without creating an account, the other shipping is available again, but not preset as default anymore, even if higher prioritised.
So we have a preferable shipping method, but thats not working as primary one, because of this. anything we can do here to make things right?
So the way I see it you want to keep the shipping method available as long as the customer is not logged in, respectively has no billing address yet. You could logically chain the billing-zip-code-condition with the customer-is-logged-in-condition so that either one has to be true to make the shipping method available.
Related
I have a Shopify store with rental products. Since Shopify doesn't handle return flows, the shop is connected to an external service, were the order is sent via an API to that service, which handles finalizing the rental and tracking it.
Now here is the problem, since the procedure is finalized outside of Shopify, the products are removed when rented, but not added when returned. this makes updating the shop manual. I am currently using Pipedream to handle my Web-hooks and requests, and it provides a service to change Inventory Level, but no direct way to update Shopify inventory. I know that the only way to update quantity in by getting InventoryItemID, and the only way to get that is by using ProductVarientID. I was able to acheive that using GraphQL, but I'd have to manually quary the InventoryItemID by using the ProductVarientIDs of my return orders from an API, and then use a mutation that does bulk inventory update to get the job done, but you can see, this is hardly automated.
Any thoughts and ideas are much appreciated.
If there is a way to do it using Pipedream, that's super.
So I have my clients app set up to work with plans, which I was testing with my account. I set those test plans a couple months back, but now that I'm setting it up on my client's account, when I create a product I can only create a price for it. Did something change. Can I create a plan or do I have to change my code?
Prices are a new abstraction that replace Plans, yes :
https://stripe.com/docs/billing/prices-guide
https://stripe.com/docs/billing/migration/migrating-prices
They're created by default in the dashboard now.
You shouldn't need to change any of your code though, it's completely backwards and forwards compatible.
You can simply pass a price_xxx ID into anything that takes a plan parameter, for example, code that creates a subscription and sets items[0].plan=price_xxx will just work. You'll also see that the API mirrors the Price into both plan and price fields when you read an object from the API so again, your code doesn't need to know a Price is being used.
I'm working on a SAAS system that allows purchases to be made through a clients own payment gateway. We have one client that wants to use Stripe as their gateway, however as they are using Corporate Purchase Cards (CPC), it is necessary to pass Level 3 transaction details through. I've been trying to get details from Stripe on how we ensure that Level 3 data can be passed through successfully, however I'm not really getting anywhere with this in terms of getting any definitive information we can work with.
Stripe say that their system supports level 3 data, we just need to provide the data in the first place, however there is nothing in their documentation about this and the example we have been provided only allows for a single item to be listed - we will need to support a basket of different items.
We are using the Payment Intents process and already support adding in Metadata to the transaction. We've been told that adding metadata for SKU, Unit of Measure, Unit Price and Extended Price will allow level 3 processing, however this does seem to fall short of the information list on other sources (not to mention does not allow listing multiple items in the order due to the metadata keys needing to be unique)
Baed on that, our Metadata population looks like this (values hard coded to example purposes)
Dictionary<string, string> nRetVar = new Dictionary<string, string>();
nRetVar.Add("Customer", "John Smith");
nRetVar.Add("Email", "John.Smith#example.com");
nRetVar.Add("Order Number", "12345");
nRetVar.Add("Order Date", "2020-02-06");
nRetVar.Add("SKU", "ABCD1234");
nRetVar.Add("Unit of Measure", "1 Pack");
nRetVar.Add("Unit Price", "$10.00");
nRetVar.Add("Extended Price", "$15.00");
Stripe support never seem to directly answer any of the questions we have been asking about this, so it's proving very hard to get any progress on this - does anyone have enough experience with this to confirm if this metadata is enough to class as level 3, or is there more that we need to be adding?
Stripe supports Level 3 data in their API on both Charge and PaymentIntent. This feature though is currently "gated" which means you need to get access to the feature on your specific account. It's a bit similar to a long running beta. You should contact their support team again and ask for them to enable Level 3 data on PaymentIntent for your account.
The fields they are expecting as specific to that feature. This does not go inside metadata. The documentation is also gated which means you can only see it once you get access to the feature, to avoid confusion for other developers who don't have access.
You can see what the shape looks like in stripe-java for example on Charge here. The feature is not directly supported on PaymentIntent in the library though as this is still private.
I'm using Stripe's PaymentRequest button to collect payment & shipping information to later process the payment with Stripe on the server side. I'm targeting ApplePay, but currently testing under PaymentRequest API (Chrome).
I need to know the customer's shipping address to calculate & show tax amount (and update grand total) before the payment form is submitted. I can easily get it via "shippingaddresschange" event, but only if the customer changes the address.
How can I get the default shipping address that the payment request form is automatically loaded with if customer doesn't change it later on? The initial (default) address does not seem to trigger "shippingaddresschange" event.
See examples at https://rsolomakhin.github.io/pr/single/ and https://rsolomakhin.github.io/pr/multi/. Chrome pre-selects an address if you pre-select a shipping option that you're OK using for any address in the world, i.e., flat rate shipping world-wide. Here you would not know the shipping address until the user authorizes the payment.
However, in your case, you need to know the shipping address to calculate & show the tax amount. This means that you don't have a world-wide flat rate, so you would not pre-select a shipping option. In this case, Chrome requires the user to explicitly approve providing their address to you, which means that the user's address will not be pre-selected in the UI as it is implemented right now.
I think this is a bug with Chrome. Safari/ApplePay will trigger an initial onshippingaddresschange when the payment sheet is displayed but Chrome does not.
I've also run into an issue with Chrome where I select a shipping address and onshippingaddresschange triggers. I then cancel/dismiss the dialog and re-open but the "default" shipping address is selected and all of the data (i.e. shipping option, tax, etc...) in my payment sheet is still set from the previous onshippingaddresschange event.
ApplePay doesn't have the same issue because it will trigger that onshippingaddresschange event as soon as it opens.
This isn't really an "answer" but I'm hoping this provides a little more context.
There's is no such thing like default shipping address. User always has to explicitly choose one before you get shippingaddresschange event. This is for privacy reasons.
We have an application in which we will be collecting addresses from users. In the current implementation, we are using a live agent to do this. Some users, when prompted for a final billing address, will say things like "Just use my billing address" or "same as my current address". THe new implementation will be a chatbot to try and fulfill some of these requests before they get to an agent.
We do have this information available via API lookup, I am asking more from a design perspective how to let our handler app (usually an AWS lambda) know that we need to do the lookup before we prompt to confirm fulfillment.
A few things I thought of:
Train the NLP to detect strings "current address" and "billing address" as Address entities
Create a new intent for utterances like these and handle them separately
Create a new entity type in the current intent (eg, not postalAddress) for utterances like these and handle them as part of the same fulfillment
Simply re-prompting the user, or asking them to state what their address is
I am just looking for the most pragmatic approach here, as this problem is different from most others we've solved.
I had a similar use case, and after investigation found that option 3 is the easiest way to handle this.
You can add a validation hook that fires when the new slot is populated. This hook can populate the value of the postalAddress slot with the associated address. This way you can keep the postalAddress slot as a required slot, without having the user manually state the address.
You can also have this validation hook fire on the population of postalAddress and add some manual testing for billing and current, but this felt to me like a manual work around for something that should be automated by Lex.