I was trying to rescue Spree::Shipping Error. What happens is , if any fedex Api doesn't give proper response , user stuck on "address" state. He can't move forword.
If the user isn't able to progress past the address state, the correct behaviour is to not allow the user forward. If a user can't enter their address, you can't determine what the shipping cost should be, and therefore can't bill the user the correct amount. Allowing the user past this stage is dangerous.
You can customize the flow of the checkout by using the Checkout Flow Customization Guide. However, this is a bad idea. Your best bet would be to figure out what the error from the FedEx API is, tell the user if it's something that they can correct, and error out if it's something that they can't correct.
Related
Reading almost the whole API reference of paypal, i am almost sure that they do not provide any kind of API method regarding donations. However i would like to check whether someone donates something to my paypal account and get some details of this transaction.
I thought of using the Activities Search REST API, however it was responding with -> "No permission for the requested operation" while i was testing it with my sandbox business account.
Anyone got any idea of how to claim this details? Do i missing something?
My last thought, was to use gmail API's to read the incoming emails that i am receiving (from paypal) when i got a donation, however i believe it's not a good solution, so its my last choice.
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 can not praise with my contribution here, because I am new user,
but would help if I can.
I have a big problem and I do not know how to solve it, please help.
In the same Paypal account with the default email address: email1#somedomain.com, there is 7 more emails:
email2#somedomain.com
email3#somedomain.com
email4#somedomain.com
email5#somedomain.com
email6#somedomain.com
email7#somedomain.com
that's the maximum allowed number of emails under one PayPal account (8).
So we are using API on several pages, and only one API signature can be done in the paypal
interface, so same API signature is used for each web page.
We would like to define where will money go - to which email address inside the same PayPal account.
We use Premium PayPal account, and we know that for logo change, email remove and so on, we would need Business account,
but for defining money receiver email address inside the same PayPal account
we suppose that it can be defined, otherwise we do not se a point of having several email addresses inside one same PayPal account.
The problem is that always is shown default email when making a purchase :S
We tried to define SUBJECT:
SUBJECT=merchantEmailAddress
N O T E: Typically, a merchant grants third-party permissions to a shopping cart...
And set merchantEmailAddress email2#somedomain.com.
In sandbox it works like a charm as soon as we put it on production, default mail is shown again.
Please if anyone had the same issue help.
Thank you very much, this forum is great and I realise that without nice people and contribution as well there would be no answers.
regards
You would not be using SUBJECT unless dealing with Permissions and making calls on behalf of 3rd party PayPal accounts.
You're working with a single PayPal account, so you won't be using SUBJECT at all. You'll use the credentials like you are already.
That said, I'm not sure I'm following you entirely what trying to send to different emails. I don't understand the end goal with that..?? The API credentials are what are going to tell the system where to drop the money, or pull data from, or whatever.
If you're just trying to get different logos to show up during checkout you can do that with parameters in your standard button code or API requests.
Let me know if that helps or not. Again, I'm not sure I'm understanding what you're after here.
I'm looking to implement an SMS authentication for one of my projects, basically before a user is able to register an account with us, we would like to authenticate the user by sending sms containing a code to his mobile phone, and get him to put in the code in our form before he can proceed.
I've been looking around and found onVerify to be a pretty good way to go
http://www.onverify.com/
But I'd like to know if there're any other alternatives similar to onVerify as it is a bit expensive, so if I could go with cheaper one, that'd be great.
Thanks!
You can do this easily enough if you have access to an SMS provider.
Typically you send an SMS to the user by making an HTTP request, containing the verification code. You'd store this code, and the recipient number, in some persistent database, against which you can compare when they fill in the details on the form.
You don't mention which geographic regions you expect your users to be in, which can be important given the variable delivery quality in some markets.
Have a look at the HTTP API for BulkSMS, message pricing and coverage.
Note that you can register in various regions, if you, for example, want to price in USD.
Disclosure: I work at BulkSMS