I have a question. How can I show certain shipping rates, based on a weekday in shopify checkout. For instance, I would like shopify to show different shipping rates on weekends, which are more expensive.
I know it should be something like this pseudocode:
Get current day of week
If day equal to Saturday and Sunday
{show these weekend shipping methods}
else
{show regular shipping methods}
Can anyone help me with the script?
Typically what we have done for a decade or so is install a custom carrier service for that purpose. By doing that, Shopify sends your App the origin, destination, and payload, to which you respond with JSON about pricing. So you get to take into account the number of days to delivery, the service levels, and how much to charge, based on delivery being a weekday or weekend.
It maybe different in 2022, but I kind of doubt it, so if you indeed control your own Shipping Rates and service levels, and want to present better numbers to customers, just put a custom carrier service into play.
Related
So I have this problem which is bugging me for past few days.
I'm trying to make a recurring payment for X month of time with Paypal.
Recurring payment itself is working find with Billing Plan and Billing Agreement, but the problem happened in the next stage.
It needs to total up to X amount of money.
So for example, If a customer wants $100 to be paid over 3 months, it will $33.33 monthly and this will total up to $99.99, not $100!
Therefore I was trying to find something that would make me allow to change the last month payment but there was no luck.
Last thing I was going to try was making two separate payment definitions (trial and regular although they both are not trial) and set one as different amount.
Is there any better idea of implementing this feature or anything I couldn't find?
And one more question - what is the difference between trial and regular payment? I know what they mean but what's different in payment wise/program wise? Can I make regular payment definition as trial so I could just have trial payment with different $$$ and then when trial ends, proper regular payment goes through?
A trial period will work for what you propose, the only disadvantage is that the verbiage might confuse the customer during checkout, since they will see it broken down that way.
what is the difference between trial and regular payment?
The difference is that one is called 'trial' and one is called 'regular', and one happens before the other. So basically, no other important differences so long as the system accepts the parameters you're setting.
FWIW, most customers would appreciate you rounding down each period and just charging them 33.33. They would think that's fair enough.
We have built an e-commerce web application (Node backend, Vue frontend). We process the payment using Stripe, but many brands have asked us if the order and inventory control can be done in Shopify. We are trying to figure out the best way integrate a payment module into Shopify so that the brand can manage the fulfilment and inventory through Shopify.
It seems we should use the Order API to create an order and mark it as paid. But how do we know that the product is in stock, and what are the cost for shipping and tax from Shopify when creating the order? I think we can use the Product API to get inventory levels, but where is the shipping and tax endpoints?
If I understand the Order API correctly, we need to tell Shopify what are the shipping costs and tax costs, when a new order is created. Is that right? How could we possibly know those figures? Seems like there should be an endpoint to calculate shipping costs and get a product's tax rates so that we can then pass those figures back into the Order API. Am I missing something?
I thought maybe we are supposed to create an order that has financial_status: pending first to get shipping and tax rates back (does it even give you those?), then update the order to either cancel_reason: customer or cancel_reason: inventory if those rates are too expensive and the order is declined? But surely we need to know what shipping methods are available to the customer in order to tell Shopify which one to use, right? Or does it by default choose the cheapest one when creating an order?
Notes:
We know the customers shipping address
We don't know where the product is warehoused (Shopify does I think)
We don't know the weights or dimensions of the product (Shopify does I think)
This answer is a little bit late, but i hope, i can help others that are struggling with the same issue.
First i would recommend to set up all Shipping Rates and Taxes in Shopify. There are plenty of manuals to achieve this:
https://help.shopify.com/manual/taxes#general-process-to-set-up-taxes
https://help.shopify.com/manual/shipping/rates-and-methods/calculated-rates
After this there are different possibilities to calculate your shipping and tax cost.
Your shipping cost can you get via the active_shipping API, which can be found here:
https://github.com/Shopify/active_shipping
Or the following Shopify Application: https://apps.shopify.com/boxify
However, you may need to know size and storage location for theese solutions.
The taxes can you get via the country in the Admin API, there is a specific key-value pair for this:
https://help.shopify.com/api/reference/country
I hope that's enough information to get closer to solving the issue, for at least someone.
I'm looking to build a Loyalty Points/Reward system on the back of the Credit payment provider, however I would like it to be able to:
Allow visitor do redeem balance or not during the basket/checkout stage
Allow visitor to pay the outstanding order amount with any of the other payment providers.
I've considered a lot of possible approaches but am wondering whether someone else has achieved this successfully?
I'd assume I'd have to tap some method on the shopppingcartinfoprovider before processing the payment with the chosen payment provider (other than credit/full amount) but how best to apply the discount to the order?
Create an actual discount on the fly? Use a faux product with a variable unit price? Are there any tax considerations I must have? Is there any other recommended best method?
Thanks,
You can apply a discount to the order in the height of the credit amount associated with the customer account. You can store the credit balance in the OrderCustomData field and subtract it after the order has been paid. You can tap into the CalculateOrderDiscountInternal method in the CustomShoppingCartInfoProvider.cs or the EvaluateShoppingCart method (http://devnet.kentico.com/docs/9_0/api/html/M_CMS_Ecommerce_ShoppingCartInfoProvider_EvaluateShoppingCart.htm). More information on e-commerce customization best practices can be found here: http://devnet.kentico.com/articles/e-commerce-customization-best-practices You can also check the code samples in c:\Program Files (x86)\Kentico\9.0\CodeSamples\App_Code Samples\E-commerce samples\
We have a series of products that are subscription based. ie: first 7 days free, then a monthly or annual fee with a start date and finish date. Is this possible ? and could we drive this through the REST API ?
Moving my comment to answer -
I would like to second #KimballRobinson's comments. It might be possible. The REST API by itself gives you access to store data. You can create products and maintain them. In your case, things to consider - what is the product taxonomy like and can it be defined as custom fields or something of that sort. Maybe you can set it up in a way such that you charge/invoice the customer for the same product every month or annually. There are ways in which you can implement subscription. If you define details more on the scope of what you are trying to accomplish, it will be easier to figure out
I am developing an ecommerce store for a client. I am not sure how to go about handling the shipping methods.
Lets say that there are two shipping methods:
Ground shipping - $10
Express shipping - $30
Buyer comes and selects Ground shipping.
However before buyer hits the checkout button the admin changes the price of ground shipping to $20. Since buyer agreed to pay $10 buyer should only pay $10.
Also for security reason when checkout is hit the order_id is sent to the server and the total price is recalculated. When this recalculation happens then shipping price has changed from $10 to $20. This is not good.
To solve this I have two thoughts.
1) When buyer selectsground shipping then clone all the attributes of the shipping to somewhere and now these values belong to order. This is less than ideal since shipping could get complicated with different shipping rates for domestic vs international etc. And cloning all those attributes might not be possible.
2) Do not allow admin to change and existing shipping method. Admin can only create new shipping method.
I tried to look at how other open source ecommerce applications handle it but could not get any meaningful information.
Option #2 is what needs to happen. Allow the admin to change the existing shipping method only when the site is down for a scheduled maintenance so you are not changing anyone's pricing costs on them "behind their back" and also so that the customers know in advance the site is going down for maintenance and maybe in the maintenance message you can mention that shipping prices may be being updated during this downtime / maintenance period.
Changing the costs of shipping on a live site while people are making purchases and shopping is a bad idea.
3) Log price changes with timestamps on server, so when recalculation is performed, the old (buyer checkout) price is calculated.