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\
Related
I have a collection of items which has a 13% tax. So if you buy $1 in goods, your final charge would be $1.13 because of this tax.
I give users the option to return certain items while purchasing others (imagine returning the keg of beer while buying another).
The problem, however, is that the "return" (where I subtract $X from the checkout) affects the checkout pre tax. So if the total was $100, which is $113 after tax, my current code would deduct $50 pre-tax, which would affect the tax I need to collect.
Is it possible to have the items purchased + tax show in the checkout, and subtract the "returns" after the price plus tax is calculated?
I have looked at this link identifying a similar issue and people claiming they can solve it. The only solution provided by shopify was to pay $2000/month to get access to checkout.liquid where * maybe * I could solve the problem.
Unfortunately, your question is unclear. You have to understand how Shopify works to accomplish certain goals. One, you cannot mess with the pricing of goods or taxes. About the only thing you can offer customers are discount codes.
Anything that gets committed to checkout is out of your control. You cannot adjust anything in the checkout, with the exception being, Plus merchants can indeed script checkout, and even alter the Liquid.
Until you are more clear about what you are attempting, I suggest you ensure that whatever you are doing, the cart is fair game, do as you wish. Have the customer replace one item with another. Submit to checkout. Be done.
Sure, there are cheesy Apps that help fake things financially by using discount codes, but that is often a road to more problems than it is worth.
we have tried this but it did not work for us.
We then ended up disabling the tax altogether
The items were calculated inclusive of tax and we would then provide a tax invoice separately using API
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.
When discount codes are applied to orders the way they are brought in in an order is a 2 field array, code and amount. Although, in the admin interface a Shopify user can choose whether or not the type of code is an absolute amount, percent, or free shipping.
In the api response is there a way to determine whether the code used was for free shipping or one of the others? This is causing issues with our sync because taxes are handled different in different locations for shipping costs compared to general order line items.
Thank you,
Brandon
Short answer: No, you can't tell the difference.
Long answer: Internally, free shipping codes are actually applied to items in the cart up to the value of the shipping method selected, and then the shipping amount is applied on top.
The upshot of this is that there is no difference between the three discount types as stored on Shopify. They're all just dollar amounts taken off the order subtotal. Therefore you can't tell whether the shipping was discounted because it never is.
Using Google Checkout, I'm able to estimate tax based on the zip code that's assoicated with a user's account when they click "Buy." The user then sees the tax amount when they checkout.
Is it possible to estimate tax based on the user-entered zip code before a user reaches the checkout page? This is similar to the functionality in Google Products currently. I see some data here (http://code.google.com/apis/checkout/articles/Google_Checkout_Articles_Zip_Level_Taxes.html) but am not sure how to implement it within the checkout button I have.
Is there any other tax table or API that allows estimation of taxes based on zip code? Does Paypal offer this functionality?
have you looked at AvaTax module?
http://www.magentocommerce.com/magento-connect/one-pica-avatax-connector.html
If your building a cart from scratch you can use avalara's api. If your using a specific package such as magento, 3dcart, or so on they already connect to the major solutions. Avalara's solution also bridges the gap between the sales software and the accounting software such as Quickbooks and Sage.
Otherwise if the company your building this for is small enough and has time to update them manually, you can go to the states website or go to a place that compiles free tax rate tables such as taxrates.com
One major warning with any solution, sales tax taxability rules can be complex, this compounds when your scaling an e-commerce business. Even if your a small business in one state, there are multiple layers to the rules. Best to work talk with an accountant to double check when your initially setting this up.
I've been researching eCommerce payment gateways and service offerings, but I'm an eCommerce novice, so please excuse my ignorance.
I wish to set up an eCommerce solution with the following requirements:
User "subscribes" to the service on a yearly basis. This service includes a single product subscription for a set amount (let's say $50/yr).
User can "subscribe" to additional product services for a lesser rate per year (let's say $25/yr).
I will need to store a product service unique Id of some sort for each product subscription the user subscribes to in order to show them product unique information. I also need to prevent duplicates...for example, user can subscribe to product ABC and XYZ, but not 2 of ABC.
Is PayPal the best solution for something like this? Is there a better solution? Any assistance is greatly appreciated, even if just links to specific tutorials or examples.
Update: It looks like Chargify could be the perfect solution.
You can also use Authorize.Net's CIM solution which, based on what I read at the chargify website, does most of what chargify does except your customers never need to leave your website. The Customer Information Manager allows you to create profiles for your members. These profiles store sensitive information like credit card numbers and billing information so you don't have to worry about PCI compliance or hackers stealing your information. You then can schedule a cron job to charge them monthly for whatever amount they owe based on their current subscription. Since you control when the payments happen it also allows you to charge them pro-rated amounts for subscription changes mid-month.
[link text][1] seems to be the best solution for me. I still need a merchant account, but this takes a lot of the headache out of handling the subscriptions.
[1]: http://chargify.com Chargify