Multiple postback URL's?

[Daniel Florey]

Hi,

I'd like to sell our cloud-based products using the In-App Payment API.

They live on different top level urls. Is there a way to specify multiple postback URL's to sell different apps with a single merchant account or do we have to setup a dedicated merchant account per item?

Thanks,

Daniel

[Mihai Ionescu]

Hi Daniel,

There is only one postback URL per merchant account, however you can easily differentiate the app and payment origin for each postback. The API allows you to pass additional information in the "sellerData" field in the JWT. Use this field to pass an app id and this info will be returned back to you in the postback.

Thanks,

Mihai

[Daniel Florey]

Hi Mihai,

unfortunately this will make our adoption quite tricky.

If I got it right, we cannot integrate in-app payment into multiple top-level applications without creating a new "postback" application that handles the postbacks for all applications.

As there is issue in App Engine that causes a deadlock when calling another app from within app engine this will force us to create a "postback" application outside google app engine just to do the application dispatching.

Are there plans to allow users to specify the postback url directly in the JWT? This would simplify the whole game.

I guess there may be other companies in the future with similar requirements.

Daniel

[Peng Ying]

What about creating multiple merchant accounts?  One for each top level domain?

--

Developer Programs Engineer

Google Commerce

Google+

[Daniel Florey]

Yes, that is what I will do (see initial question). But it would be nicer to have everything in one place ;-)

Daniel

[Peng Ying]

True true, limitations of the platform.  We have a pretty good roadmap of upcoming features though and the question is something like would you rather have these new features that would enable new revenue models or fix this which kind of works but is a little bit clunky.

On Wed, Feb 1, 2012 at 5:06 AM, Daniel Florey <daniel...@gmail.com> wrote:

Yes, that is what I will do (see initial question). But it would be nicer to have everything in one place ;-)

Daniel

[Daniel Florey]

Both ;-)

I've no idea if there a some security implications, but passing the postback to the JWT seems quite natural to me.

Highest priority (when it comes to a personal wishlist): Recurring payments...

Thanks again.

Daniel

[Peng Ying]

Haha, yeah if you know of any fantastic engineers that are looking for employment let me know.

[Avanish]

Hi Daniel,

It would not be very difficult to redirect the payment feedback POST
to the multiple websites. If you have some kind of standard format
identifier build into your sellerdata field, you could do the repost
from one of your main assigned server/websites. Maybe it would be more
organised to keeps just one website to take care of payments.
I've created a very light weight store gadget where you could see the
feedback post and your buyers access. We specialize in creating
something out of ordinary, such as in your case. I can redirect the
post to the desired destination on the server-side , let me know if
you require assistance.

See http://inappstore.analyticsworkspace.com/

Regards,
Avanish

[Daniel Florey]

Thanks for your suggestion. I'll stick with the approach to create multiple merchant accounts - hopefully they can be linked to the same bank account...

Redirect is not a good option for me for 2 reasons:

- There is an GAE issue that causes a deadlock when calling another GAE using URLFetch (A1->A2->A1 = timeout)

- Each redirect will add another point of failure which is not good in context of payment

Allowing a dedicated postback url per-app would be by far the best solution.

[alz]

this is a clever solution but a lot of faf for something that is supposed to be really easy to impliment

[alz]

both would be great : >

[alz]

this is not very dry, so suddenly we have 12 accounts and if we wanna change 1 thing we have to do it 12 times.

sellers should be allowed multiple apps, no?