I'll be precise, i have been trying to add a custom gateway to bigcommerce, i have been somewhat successful till now, now i am stuck on bypassing the checkout page, i am unable to add additional option in checkout payment options, i'm able to do it using javascript, but then order is not being processed, and second thing, even if i am able to add option, and redirect user using javascript, how am i suppose to empty the cart once user has returned to the site?
I'm completely stuck here, any help or pointing to the right direction would be greatly appreciated.
For anyone who wish to achieve the same as i needed to, here is i went about it,
i didn't touch the actual flow of the order and checkout, what i did, i renamed one of the offline payment method as the third-party gateway i wanted to integrate, then after checkout, user lands of thank-you page, on thank-you page, i embedded my script, which picked up order-id from thank-you page, and checked the payment method that was used during checkout, if it matches the one i required, then i redirected user to external url ( additional domain on another hosting ), where user and order details were fetched using order_id ( which i sent via ajax ) and the payment was processed, and in the end, user is redirected back to the bigcommerce store.
Things that you will need
Additional domain
Additional hosting, to point that domain to, and to execute payment-gateway processing code and also to update order status in bigCommerce via their API.
It is kind of a complicated process, but once you get the hang of it, it becomes pretty simple after that.
Related
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 using Paypal rest api to make payment
the workflow is:
Create payment
Redirect to approval Url
User approved (return back to my site)
Execute payment
But there's one thing that I don't want users re-filling shipping address again because it was filled in my website.
So I change the workflow to:
Create web profile (set no shipping field)
Get web profile ID
Create payment with experienceProfileId given
Redirect to approval Url
User approved (return back to my site)
Execute payment
But I found this will create a lots WebProfile every time user request payment.
I think it is crazy to do:
create and delete it later again and again
attempt listing WebProfiles and check which is the one I want to use every time while creating payment
store experienceProfileId as a constant
What is the best practice for handling WebProfile or does there any solution just hiding shipping address while user approving payments?
Maybe this is not the answer regarding this "WebProfile". As a fact, I dont know what exactly "WebProfile" does or is.
I worked on the same Workflow these days. As you wrote I needed to predefine some address. For me it was obvious, that I have to do the database-stuff on my Website. Then I exactly define the order, shipping_address, etc. and send the users to Paypal.
If you predefine the new ShippingAddress() to your ´new ItemList()´ by
$itemlist->setShippingAddress($shippingaddress) the user cannot change it within the Process.
http://i.imgur.com/nAg8jxU.png
Maybe this helps you a little.
I'm trying to track clicks from our site to an external website. On the external website, I'd like to place some code on their checkout thank-you page, that tells our server that a particular click has resulted in a sale.
How does this tracking code work? Does it need to be a pixel? Do we need to drop a cookie before we send the user to the external website?
Thanks.
Pixel-based conversion tracking is pretty straightforward. You set up a basic web server to accept HTTP GET requests and write logs for those requests. On the merchant's confirmation page you put an image where the src attribute is a URL on your tracking server. That URL contains any data you need to collect for the sale, which will show up in your server logs.
(No, this doesn't need to be a pixel. It can be any excuse to make a client request something from your server. XHR requests, script tags, etc will work just fine.)
Example: if you need to know the Order ID number and value of a sale, you could have the merchant embed a pixel that looks like this: <img
src="http://tracker.example.com/i.gif?orderID=12345&orderVal=99.95">.
Your server logs will now have a record of sales generated on
that site.
Now you need some way to separate sales you generated from the rest of them. There are three ways to go about this:
you do the tracking,
merchant does the tracking
you work with a third party.
An affiliate network can be that third party, the merchant can track traffic sources and use that data to decide when to display your tracking pixel, or you can track it yourself. Which way you go depends on the terms of your partnership.
One popular and easy way to track which sales are yours is to set a cookie on the same domain as the tracker. Since many clients will block 3rd-party cookies, you will track best if your tracking server is also a redirection server.
Example: on your site you make outbound clicks go through your
tracking server. Whereas you used to have an <a> tag that pointed to
http://destination-site.com/landing-page.html you now send traffic
to: http://tracker.example.com/redirect.php?url=http%3A%2F%2Fdestination-site.com%2Flanding-page.html. In this example, redirect.php
should set a cookie and a redirect to the
destination site.
Your server logs will now have that cookie value on image requests from
the merchant's confirmation page, along with any other data you passed
in the cookie (or associated with it on your back end). Now, when you look at your tracking
server logs you know the image requests with cookies are yours and the others are not.
Things start getting complicated when there are more parties involved, deeper reporting needs, accounting and PII policies to comply with, concerns over fraud, etc but that's the gist of it.
I have a single authorize.net account, and I have 5 different e-commerce applications tied to that account. Some are posting from a public site and some are posting from managed access sites. I am using SIM and I have read about the Relay Response, but as far as I can tell I can only have one URL listed. That will not work for me as I need a different URL for each different point of entry into the e-commerce system.
My problem at the moment is that I need to update a datafield via a guid upon successful payment completion to confirm purchase of a digital item, but if I put in a relay response page it is getting sent to all my access points and throwing errors. Other parts of the e-commerce system need to send different emails upon completion etc, plus all the urls are different at the top level.
Is there some other way of accomplishing this task that I am overlooking?
Use Silent Post*. It's Authorize.Net's equivalent of Paypal's IPN. It will only post to one URL per account but it happens behind the scenes. This means you can send a custom flag along with each transaction identifying which site the purchase is for and then have it respond accordingly (e.g. send emails, update database, etc).
*I am the author of this content
We use WorldPay as our payment gateway and we've specified the callback URL to be myurl.com/payment.php, however worldpay doesn't actually redirect to this URL, it passes some parameters to it, ie, whether the payment was successful, how much for, etc and then displays the result through a worldpay server.
What I want to do is implement Google Analytics eCommerce tracking (instructions found here: http://code.google.com/apis/analytics/docs/tracking/gaTrackingEcommerce.html ). But this requires javascript which isn't enabled on the worldpay server.
I could do an immediate meta refresh to myurl.com/analytics.php which displays, aesthetically the same screen, but is actually on our server, so the JS will work.
The question is, how do I pass the cartID, if i'm using a meta refresh?
See: http://www.tatvic.com/blog/google-analytics-worldpay-ecommerce-tracking