I am using "ConvertPlus Default" Checkout Theme in 2Checkout to accept international payments from my customers across the world. I generated the Buy Link and integrated with my store.
My issue is that the Checkout Form is not showing fields to input Address and City for many countries including Mexico, Japan etc. Refer screenshot below:
How do I enable the option to accept Complete Address information for all countries across the world?
Buy Link looks like this:
https://secure.2checkout.com/checkout/buy/?merchant=\[MerchantID\]&prod=\[ProductID\]&qty=1&tpl=default
You should add the tangible parameter
Send tangible=TRUE or tangible=1 for products that require physical delivery.
As of 10/01/2019 the parameter you will need to enable shipping is
li_#_tangible
The documentation says this.
Specifies if the corresponding li_#type is a tangible or intangible.
( Must be Upper Case, ‘Y’ or ‘N’, if li#_type is ‘shipping’ forced to
‘Y’.)
Where # is the parameter number. Because you can send multile items in the same POST so it will appear as multiple items in the 2CO cart.
Here is the full documentation about parameters,
https://www.2checkout.com/documentation/checkout/parameters/
Hope this helps someone.
Cheers.
Related
I just want to ask the community if you have any idea, how to create a unique header for a specific page on shopify.
Theme is Venture(Free Version)
I want to have UK page and US page on my shopify store. My index page is UK based or international clients. While the US page is for US customers only. I want to have a different header and navigation for US page since there are products that are not available for US customers. I just want to post US only products.
Anyone can help me with this? Thank you!
This will require more than just a header change, but it is possible to have two separate headers.
However, the localization may be tricky.
According to Shopify docs:
Your theme's primary language cannot be a regional variant when using
Shopify Markets. For example, you should not change your primary
language to English (United States). It should be English.
This can be done by assigning an array of IP addresses to an variable that is placed in several conditionals.
This process is far too advanced for laymen. If you are not comfortable with liquid and javscript, You can use Nosto or the app Geo-targeting.
If you are looking to do this yourself, please refer to the docs regarding the ‘browsing_context_suggestions.json’ endpoint.
This will then need to be compared to an array of some sort that will assign your customers to a region.
Then, assign that endpoint to a variable and use that variable as a conditional to display your menu with:
{% assign menu = [british menu] %}
I know how to do this, so if you need help I can set it up. It just won't be free, and I recommend trying the apps before you hire unless you are scaled properly for development.
You will then need to lock your products by region, which is done in ruby. You have limited access to ruby through liquid, and backend editing of this sort requires an app. You cannot region lock products in front end without a ton of work and it will be extremely unstable, expensive, and will not lock search results regionally.
So try Locksmith to region lock products. I haven't used it, so my suggestion is blind there, and some experimentation may be required.
I'm using vatlayer API for getting company information by put in the vat number. https://vatlayer.com/documentation
Now I want split address info in the state, zipcode, addressline and address number.
I get the address info: BREDABAAN 13052900 SCHOTEN.
The address number and zipcode stands against each other without spacing. (1305number and 2900 zipcode).
Is there another API for working with the vies database where i can split these information? Or an work around for this bug?
VatLayer don't support the split atm.
I get the address information by:
$("#organisation_address_line_1").val(json.company_address);
Thanks in advance,
There's quite a lot of API's to handle VAT validation but the ones that provide information about the trader essentially all rely on the official API at http://ec.europa.eu/taxation_customs/vies/checkVatService.wsdl . It connects directly to the VIES system. Perhaps the values returned there are a bit different: it's worth trying your validation that way as well.
Unfortunately, since VIES does not return structured addresses (except for approximate matches, but only Spain supports them at the moment) and does not specify a common format for the free text addresses, you're going to have to deal with whatever format the country has chosen to provide, which means manual parsing.
I reckon 3rd party wrapping API's could handle guessing the format and splitting the formats on their own but I am not aware of any that would do it.
We are wondering if in Hotcakes 1.10.3, if the shipping method lookup can recognize if an address entered is a P.O. Box before returning available shipping methods.
Why we ask - our client is primarily using FedEx to deliver shipiments, but would like to default to USPS shipping methods when a customer enters a P.O. box as FedEx doesn't deliver to P.O. boxes.
I've tried out a few PO box addresses, and in our current build FedEx rates still get returned. Is there any way to block FedEx from returning if a P.O. box is entered as an address in Checkout?
Thanks much.
Disclaimer: I work for Hotcakes.
I looked at this in our code base and it was interesting to see that we're simply taking the address entered by the customer in checkout and passing it directly to the shipping provider (e.g., FedEx). In my testing using FedEx specifically, they're returning rates from their own web service, regardless to whether the address is a P.O. Box or not. They don't seem to be checking for this themselves. I didn't check the other built-in live rate providers for this answer.
I order to workaround this, you can detect this yourself and prevent this from happening in your custom viewset. However, you should be aware that doing this would really require that you test all of the use cases that you expect for your target customers to fall into on your site.
In your viewset, find the Checkout.js file in the Scripts folder.
In this file, you'll want to look for the following method and apply a check to see if the Address 1 field is a P.O. Box or not. If it is, remove the FedEx rates from the list of shipping providers that received rates. This will prevent your customer from selecting unsupported rates.
RefreshShippingRates
An example of that check in this JS file might look like this:
var address1Value = $('#shippingaddress').val()
if (address1Value.substring(0, 4) == "P.O.") {
// iterate through each rate to see if it needs to be removed
}
In Prestashop 1.6.
I don't understand why the Carrier Name field is not translatable anymore.
I found serveral topics just saying that this was posible in older versions but no now. But why?
I have names like: "Standar Delivery" How are we supposed to translate these names?
Is there other approach to work with carriers and languages?
thanks.
There is no way to translate carrier names and there is issue (improvement) opened in PS Forge since 1.4. I think the reason behind is that carrier usually has a name, e.g. DHL which does not need to translate.
I see in merchants' stores they use store's name as carrier. e.g. if you have Shop ABC, then carrier name would have the same name - Shop ABC.
If you have more than one carrier, e.g. Priority Shipping, Standard Delivery, etc. then it won't work. My suggestion would be to use Standard Delivery and below there is a field named Transit time which is translatable. It is actually the same as description so you can add short description about each carrier in different languages. Customers won't need to know which type of delivery is offered by the carrier name, they can read description next to its name.
Also it would be good to have informational (CMS) page about delivery types and costs. I would say it is a must for an online store.
i have done this before for PrestaShop 1.6
I know it's possible but you need to modify 2 files and you need to adjust the database.
I'm planning a new Shopify project, and the site requires a different shipping cost depending on the postal area of a postcode (e.g. SE1, N7). The plan was to manually add different shipping options inside of Shopify, then AJAX GET /cart/shipping_rates.json, and manually filter to the correct shipping rate by matching the name to postal area.
But my question is -- is there any way to carry over this shipping method to the Checkout as a selected option, and hide the Shipping Method drop-down from the checkout to prevent them choosing a different the shipping cost?
... Or, ideally, is there a way for me to directly override shipping costs through the API?
I don't know of any onboard functionality, which can facilitate this.
But there is a quite hacky workaround, that I use to filter the shipping rates in the checkout page.
Through the "Additional Google Analytics Javascript" field you can sneak a JS on every page of the shop, including the checkout. Here you can basically manipulate the shipping rates as you like.
In your case, the code must be aware of the shipping_address zip code. You can try to set a cookie on the first checkout page and then read the same cookie on the second.
Unfortunately, this isn’t possible with Shopify’s existing checkout.