![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
dennisgorelikSome PostJobFree users are getting "Your cart cannot be processed because it contains more than one digital item." error when they try to subscribe for Premium Membership.
Googling the errors shows that this bug is about two years old
So I opened a ticket.
Here are excerpts of my conversation with Google Checkout Support in the course of days and weeks:
========
Google Checkout support: I understand your buyers are unable to complete purchases.
...
Google Checkout support: One of the limitations of the currently mobile buy flow is that only a single digital item may be purchased at a time.
...
Me: Do you log more detailed description when you show that cryptic error message?
...
Google Checkout Support: We typically log errors in the Integration Console, but I don't think this error was logged there.
[Me thinking: "You cannot even log your error messages?"]
Google Checkout Support: I've only seen that error displayed on mobile devices. Could they have
been purchasing from an iPad or Android Tablet?
[Me thinking: "Why can't you trace it yourself?"]
Me: I explicitly asked him if it was mobile or desktop and he replied "Desktop".
Google Checkout Support: Try asking him to try a different browser. Also screen shots will help
tremendously in debugging as to the best of my knowledge that error message will not be logged.
[Me thinking: "Great. Now you, tech guy, is asking my non-technical users to do non-trivial exercises just because you could not setup proper logging on your system."]
Me: This is an error that happens with another customer.
[Attached screenshot of user's browser screen when "Your cart cannot be processed because it contains more than one digital item." happened again.]
Google Checkout Support: That's odd are they modifying the user-agent? The /m/ in the URL
indicates that they're reaching the mobile buy flow.
[Me thinking: Google Checkout defines that URL and sending it to me. Who if not Google Checkout Support can find out why that URL was generated?]
Google Checkout Support: One current limitation of the mobile buy flow is that only a single
digital item can be purchased at a time. We're working on improving the
buy flow, but the current work around is to specify the item as a physical
good.
[Me thinking: Yay! At least they have a workaround!]
Me: Can you guestimate when mobile workflow would be fixed in Google Checkout? Is is about weeks, months, or years ahead?
Google Checkout Support: It'll likely take months before the update is released. I'm honestly
don't know why the user is being redirected to the mobile version.
[Me thinking: That's really good to know.]
Me: Could there be any consequences if I sell digital subscription as physical good?
Google Checkout Support: Ah yes you were specifying a subscription. Defining the subscription as a physical good would probably work just as well. I don't think there are any compliance consequences.
Me: Thank you - we'll try to switch to using "Subscription for physical good" option in order to overcome that disappointing error.
Google Checkout Support: Yeah it's quite odd. Let me know if you ever figure out why they were being redirected to the mobile buy flow.
Me: PostJobFree redirects users to whatever "redirect-url" element
contains in Google Checkout response XML.
I may try to log these URLs or even whole response XML.
Would you like me to do that?
Google Checkout Support: [no reply]
[Me thinking: I guess Google Checkout is not really interested in troubleshooting their bugs.]
========
Googling the errors shows that this bug is about two years old
So I opened a ticket.
Here are excerpts of my conversation with Google Checkout Support in the course of days and weeks:
========
Google Checkout support: I understand your buyers are unable to complete purchases.
...
Google Checkout support: One of the limitations of the currently mobile buy flow is that only a single digital item may be purchased at a time.
...
Me: Do you log more detailed description when you show that cryptic error message?
...
Google Checkout Support: We typically log errors in the Integration Console, but I don't think this error was logged there.
[Me thinking: "You cannot even log your error messages?"]
Google Checkout Support: I've only seen that error displayed on mobile devices. Could they have
been purchasing from an iPad or Android Tablet?
[Me thinking: "Why can't you trace it yourself?"]
Me: I explicitly asked him if it was mobile or desktop and he replied "Desktop".
Google Checkout Support: Try asking him to try a different browser. Also screen shots will help
tremendously in debugging as to the best of my knowledge that error message will not be logged.
[Me thinking: "Great. Now you, tech guy, is asking my non-technical users to do non-trivial exercises just because you could not setup proper logging on your system."]
Me: This is an error that happens with another customer.
[Attached screenshot of user's browser screen when "Your cart cannot be processed because it contains more than one digital item." happened again.]
Google Checkout Support: That's odd are they modifying the user-agent? The /m/ in the URL
indicates that they're reaching the mobile buy flow.
[Me thinking: Google Checkout defines that URL and sending it to me. Who if not Google Checkout Support can find out why that URL was generated?]
Google Checkout Support: One current limitation of the mobile buy flow is that only a single
digital item can be purchased at a time. We're working on improving the
buy flow, but the current work around is to specify the item as a physical
good.
[Me thinking: Yay! At least they have a workaround!]
Me: Can you guestimate when mobile workflow would be fixed in Google Checkout? Is is about weeks, months, or years ahead?
Google Checkout Support: It'll likely take months before the update is released. I'm honestly
don't know why the user is being redirected to the mobile version.
[Me thinking: That's really good to know.]
Me: Could there be any consequences if I sell digital subscription as physical good?
Google Checkout Support: Ah yes you were specifying a subscription. Defining the subscription as a physical good would probably work just as well. I don't think there are any compliance consequences.
Me: Thank you - we'll try to switch to using "Subscription for physical good" option in order to overcome that disappointing error.
Google Checkout Support: Yeah it's quite odd. Let me know if you ever figure out why they were being redirected to the mobile buy flow.
Me: PostJobFree redirects users to whatever "redirect-url" element
contains in Google Checkout response XML.
I may try to log these URLs or even whole response XML.
Would you like me to do that?
Google Checkout Support: [no reply]
[Me thinking: I guess Google Checkout is not really interested in troubleshooting their bugs.]
========
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2011-05-20 10:41 pm (UTC)no subject
Date: 2011-05-20 10:45 pm (UTC)no subject
Date: 2011-05-20 11:33 pm (UTC)------
So the server to server post response is returning the /m/ URL?
Can you provide the cart you post, the URL you're posting to, and the
response XML?
------
Will log and give that to them.
no subject
Date: 2011-05-21 05:50 am (UTC)Чем тебя оттолкнули fastspring, swreg и другие человеческие регистраторы?
Я на днях переключился с shareit на fastspring - как мне стало хорошо... А shareit получше гуглочека будет по отзывам...
no subject
Date: 2011-05-21 01:22 pm (UTC)А потом руки не доходили до того, чтобы что-то другое прикрутить.
Но уже пора.
На самом деле я думаю использовать PayPal Payments Pro.
Ты думаешь лучше использовать FastSpring?
Как у них обстоят дела с fraud-prevention?
no subject
Date: 2011-05-23 03:50 am (UTC)Я быстро просмотрел ревьи вот тут:
http://successfulsoftware.net/2009/10/12/a-survey-of-ecommerce-providers-for-software-vendors/
и на m-ISV форуме, и выбрал fastspring. Мне нравится что получилось.
Хотел бы дешевле - взял бы swreg.
> Как у них обстоят дела с fraud-prevention?
Да наверное так же, как и у всех. Я не думаю, что в 2011-м году в этом ещё есть какие-то различия. Впрочем у fs может быть красивее среднего: в логах видно попытки авторизации, которые не сработали - поучительное зрелище.
no subject
Date: 2011-05-23 04:28 am (UTC)Из моего опыта с Google Checkout - иногда проходит, хоть и нечасто.
Чем именно для тебя лучше FastSpring?
Я так понимаю, ты своих покупателей отправляешь на сайт FastSpring?
А можно ли с FastSpring покупателей отставлять на своём веб сайте?
Используешь ли ты recurrent subscriptions?
no subject
Date: 2011-05-23 06:06 am (UTC)Я имею ввиду, что это очень конкуретный рынок, все его игроки грызутся зубами за каждого клиента. Базовые фичи должны быть у всех неплохи.
> Чем именно для тебя лучше FastSpring?
Удобно для кастомера, удобно (просто идеально - верх продуманности) вставился мой кейген, хороший кастомер суппорт для меня и для кастомера, быстрый удобный сайт с разумными репортами и аналитикой.
> Я так понимаю, ты своих покупателей отправляешь на сайт FastSpring?
Ну, для кастомера это наверное так не выглядит. Но вообще-то да.
> А можно ли с FastSpring покупателей отставлять на своём веб сайте?
Может и можно - но нафига? 80% их ценности в том, что исчезает геморрой с номером кредитки кастомера и SSL-ем. Я такое делал когда-то вручную, и не хочу трогать трёхметровой палкой - т.е. не хочу, чтоб цифры кредитки касались микросхем памяти моего сервера. Если хочется абсолютной бесшовности, можно их страничку раскрасить под свой сайт.
А вот, кстати - точно можно. У них есть платежный API для втыкания даже не в сайт, а вообще в программу. Чтоб платить без браузера.
> Используешь ли ты recurrent subscriptions?
Нет, но у них оно есть.
no subject
Date: 2011-05-23 11:22 am (UTC)Номер можно просто не сохранять на диск.
А SSL мне мой hosting provider установил.
Абсолютная бесшовность невозможна при перенаправлении пользователя на другой сайт. Некоторые пользователи это замечают.
Браузеры это замечают и в случаях супер-осторожных настроек (например Internet Explorer на Windows Server по умолчанию спрашивает пользователя про каждый новый домен).
no subject
Date: 2011-05-23 02:54 pm (UTC)Например в том, что их много и они разные. Включая трёх-четырёхциферный код.
Тяжело аккуратно и красиво их поддерживать самому, да ещё на разных языках.
> Номер можно просто не сохранять на диск.
А тогда зачем его вообще самому принимать?
> Абсолютная бесшовность невозможна при перенаправлении пользователя на другой сайт.
Абсолютная бесшовность невозможна просто при переходе с http на https и обратно. Да и не нужна она, собственно.
no subject
Date: 2011-05-23 05:55 am (UTC)