Shopify Gurus! I'd like to know if any one of these is possible:
Step in at the checkout process and submit some user input for validation using a 3rd-party API
Submit certain details of an order to that same 3rd-party API for validation from the management panel (for instance, as the store takes the order to begin processing it)
The validation results in either case will need to replace the user's original input.
Short answer: No to both.
Long answer:
Steps 1 and 2 of the checkout are a black box, no external content is allowed. Therefore you can't add extra stuff to either of those pages.
Post-checkout you can send details off to a third party for validation, but in general orders are immutable on Shopify. There are a couple of exceptions to this:
Status: You can update the status of the order through the API
Order Notes: You can add notes to the order through the API
Neither of these options allow for the updating of customer info (shipping/billing addresses, payment information, etc.). You can however notify the merchant that the order is invalid for whatever reason and cancel it. This is most useful for fraud detection services.
Related
So we're building a buy-now-pay-later store module in our web-app that will be integrated into Shopify (via Shopify's Storefront APIs).
Our users should be able to make orders through our web app (without payment), and then someone on our end will be able to fulfill the order.
The user would then able to make their payment after the fact (via a custom payment implementation handled on our side), and then a webhook would just update the payment status from 'Pending Payment' to 'Complete' on shopify.
Is this possible via Shopify's APIs? We're trying to find a way to directly create an order without requiring payment, but our devs aren't having that much luck.
It is very much easy to do when you work with Draft Orders. That allows you to create a comprehensive near perfect order in the store. The main advantage is, you get define the payment using API calls. So you can convert this Draft Order to a real one, requiring a payment, when you wish to actually charge the customer, and you do that with code. They are sent an email with a link to a real checkout, allowing them to actually pay. You can also convert the Draft Order to a real order, without sending the customer the generated link to make a payment, and therefore, you can fulfill a real Order in the store, and get the customer to pay later, when you wish.
We ship using FEDEX and UPS, and we never found a need to post the tracking number to the payment record, however, recently a customer did a charge-back and the claim was that the order was not shipped even though it was. The tracking number was not entered into paypal, but we do have a tracking number for this order. Do we need to manually enter every tracking number into Paypal, or do we have a chance to enter it after a chargeback attempt has been made?
PayPal's standard API does not provide a field for tracking numbers in their order details, so there is no way to automatically send PayPal this information for all orders.
Their API supports disputes, so it could be possible, however it looks like it could be very messy. The workflow would look like this:
Use PayPal's Customer Disputes API to GET all disputes with a dispute_state of REQUIRED_ACTION and reason of MERCHANDISE_OR_SERVICE_NOT_RECEIVED. Save the Order ID
Cross reference the Order ID with your order management software's API to get a tracking number. If the tracking number exists,
Use PayPal's Customer Disputes API to escalate the dispute to a claim and save the returned claim API endpoint.
The documentation gets a little fuzzy here and may require some contact ith PayPal's support team, but it looks like you should be able to POST evidence to the claim with PROOF_OF_FULFILLMENT, which includes tracking_number and carrier_name.
Unless you are processing a high volume of these missing order claims it probably won't make sense to go through all this legwork. If it truly is taking a lot of time and energy for you or your staff to handle this specific type of PayPal dispute then maybe it would be worthwhile. I might also suggest in this case to start toggling the "signature required" settings for your shipping partners.
I have e-commerce site that I am currently decoupling so it serves as pure backend.
For shopping cart to become an order there is a workflow(checkout) in place that the customer has to go through to place an order. With the checkout now being a backend service I wonder how should I approach it.
Specifically, each new order has to have: items, billing address, delivery address, payment method and shipping method. Admin can create additional fields, alter the flow(order of steps) and so on. With API-centric architecture, I am not sure how to communicate the flow with frontend.
Sure, the frontend will handle the flow, basically, on its own. But for example in the backend logic, the shipping method depends on the provided delivery address and payment method depends on the billing address - to prevent use of cash payment method for customer form different country or to use local bicycle carrier for international destination... for example.
How should I communicate to the client what data are needed, in which order(dependencies), what data I already have and what additional data has to be provided?
You basically handle this with exceptions if the front-end does something out-of-order. The statefulness of it means that you need to create something, then modify it multiple times. If you want to enforce this, you would basically create an order (with items),
POST /orders <new order>
POST /orders/<ordernum>/items
POST /orders/<ordernum>/billingaddress
POST /orders/<ordernum>/shippingaddress
GET /orders/<ordernum>/availableshippingmethods (throws an error code if billing address not set)
GET /orders/<ordernum>/availablepaymentmethods (throws an error if shipping address not set)
POST /orders/<ordernum>/shippingmethod (throws an error if billing address not set)
etc... Just set up your step dependencies, and throw errors if they do it wrong.
This way the business logic stays on the front-end, and the API requirements for the flow are fairly self-describing (trying to get the shipping method tells you what you forgot to do).
I have a requirement to do 3rd party age verification before I ship an order. I'm using a company called EVS for this. They released a shopify app recently, but seems partly baked. It requires a user to enter date of birth when registering for an account and then triggers the verification when the user places an order. The main problem with that is that it's rare for a customer to actually create an account before ordering for the first time -- instead they order first, then shopify emails them to create an account after the fact. Creating the account afterward does not allow the customer to enter DOB.
So I'm planning to implement my own solution. I can use EVS's API to run the verification by sending a combination of Name, Address, DOB, DL# and State, and last 4 of SSN. I have already built a proprietary order management system that pulls in customer and order data, and I can write a client to perform the verification.
I'm less savvy on the shopify side. I need to balance customer friction when placing an order for the first time, against having to do a lot of manual work for verification.
Below are the options I have conceived. Are there any other options? Any ideas for a better solution? Keep in mind I need to verify a customer once. I can tag the customer account as verified, and once verified it's business as usual.
Alter shopify templates to only show the checkout button when a user is logged in. If not logged in, show a "Create an account" button instead. That way the user provides DOB during account creation and the EVS app works as designed.
Set up a separate verification site like verify.my-domain.com. I can trigger an email to the customer upon order creation and ask them to verify. (May have issues with incorrect email addresses or spam filtering.)
If customer is not logged in, or account is not age verified, and they click Checkout, I can redirect them to a page. I can use a form on the page to do the verification. If verification passes, send them on to checkout.
For option 3, I don't know what shopify allows or what best practices allow. Can I use js to pass data to my own server on a different subdomain? Or post the form to another subdomain and then redirect back to shopify?
I'd appreciate any thoughts or suggestions.
You have pretty much summed up all your options, to clarify on them a little:
You can require that customers create an account in the store checkout settings. /admin/settings/checkout
This would work, you could iframe it in too on a custom Page. Or, better, use cross-domain calls or jsonp.
This is a little convoluted and you would have to persist and maintain lot of external state. I'd avoid this
I think a combination of 1 and 2. Turn on "require customer account". Modify the customer account creation page. Implement a cross domain policy with your server which will host custom code leveraging the EVS API.
I'm not sure if you are selling tangible goods or not but with stringent policies on users' age you have to bear in mind that shipping addresses could change. For a tight integration you should look at having webhooks whenever a customer is changed and make sure all their data is still valid since their last EVS approval.
I've been looking into this quite extensively and we've spent a number of hours experimenting with options. Our client in this case is on Shopify Plus so we do have the benefit of access to checkout.liquid.
Our research has led us to believe that one cannot pass the required 'customer note' of the date of birth to the checkout should they be attempting to checkout as a 'guest'. Perhaps because the 'customer' does not yet exist.
Our options have been narrowed down to:
Write a custom backend app that allows Shopify and EVS to communicate directly (XML API on the EVS side) in the checkout process or just prior and then pass the verification status back to Shopify to allow the order to proceed, or append some relevant status marker for the fulfillment department to act accordingly. The EVS app doesn't prevent the order from proceeding, but does flag the customer's age as unverified in the Risk Level panel in the admin. This would be quite a substantial project and by no means low hanging fruit. There is also risk of re-doing a lot of what the EVS app does already and running into they same obstacles they did.
Force customers to register prior to checkout (if not signed in). This seems the most viable approach. The only caveat being that existing customers will not have the customer note (birth date) and we'd need to build a smaller backend app to allow them to append this to their customer account via the Shopify API (this cannot be done via liquid).
These are our findings and I'd love to know more about how you ended up approaching this.
I'm working with an external analytics app that requires us to collect email on the /cart page. To save the customer from having to enter their email address again, I'm wondering if there's a way to send that email to the payment form.
You can use the Shopify API to interact with orders, specifically looking at the API documentation you should be able to achieve what you want.
Which language do you code in?/Can you code in?/Would you like to achieve this in? (For example, Ruby, PHP, ASP..)
You can access a users email address from the Order if you know the Order ID..
The Order ID can be found by querying the Shopify orders API based on whatever your criteria are.
Alternatively as per Csaunders answer you can use a Shopify Web-hook which will notify your server when a specific event happens - think of it as an event trigger.. For example:
Customer raises an order
Shopify notices your shop has a web-hook active and so uses it
Your web-system receives all of the order info over a POST request in XML format
You extract the Email address (for example $email = trim($xml->email); )
Push the $email you extracted to whatever your analytics system is
Without further info about your case and setup and what knowledge you have I will struggle to improve this answer - if however you come back and add some more detail or comment on this post I will try to help as best I can.
Thanks