I'm looking for some guidance about the architecture that should be in place to process our web orders.
to illustrate my needs, here is an example:
My website sells bundles of offers. Say I have an "eat-and-watch" bundle made of 2 offers:
A pizza + drink bundle
A specific football game to watch over the internet
A customer buys the bundle on my website.
the website has a shopping cart functionality and the cart contains my bundle (and the 2 offers in the bundle)
After customer pays, I need to send an order to the pizza company and to the TV company.
I'm thinking of 2 solutions:
Option 1: My ecommerce platform should have an "OrderManagement" microservice that would split the cart into 2 orders: one for the pizza company and one for the TV company and then send the 2 separate orders via APIs. This sounds complicated as I need logic to decompose the order and send the right product to the right recipient.
Option 2: My ecommerce platform OrderManagement microservice just send one order "event" by API on a API gateway, that will, in turn, "broadcast" thi event. the pizza and the TV companies systems can listen to my events and pick the order. The obvious issue is that each company (pizza and TV) is now responsible for decomposing the order, take what is relevant for them and ignore the rest.
what is the best way to generate my individual sub- orders and send for fulfillment to other systems. That sounds like a lot what Amazon does: 1 shopping cart -> pay -> create many orders for various fulfillment systems.
Related
I asked this question directly to the Google Analytics community with absolutely no answer.
The question is as follow:
I have a AI based site, which give a customer a specific aid to select the right product he/she want to buy. The front ed application is React/js based.
My site is usually a small icon on a merchant site, and the user, while he/she is navigating the merchant site, can decide to recall clicking on a specific icon.
Then my site opens and help the user to select the right product(s) belonging to the merchant site. The product are choosen and then clicked to be added to the merchant cart.
Of course, there is a written agreement between the merchant and I to be signed, and some changes to the merchant site to incorporate my clickable icon: I'd like to pass a piece of code to the merchant including the icon and all the code needed to implement this kind of application.
So, given that the merchant call my site passing a specific transaction related token and the customer info (if any) when the user click on my icon, how can I:
directly add one or more items into the merchant cart
track the action made by the user after he/she leave me site and return to the merchant one to conclude the journey with a payment, so I can later invoice the merchant for the right commission
track if the user remove some (or all the) item from the cart, so I have less to nothing commissions to invoice.
I tried to follow the instruction given by google, but they are a mess, and I wasn't able to reach any conclusion.
Any help will be really appreciated.
Adding items to the merchant's cart is possible using some live API that the client would extend, but the easiest way to do it would be just using the window.postMessage(). So, I would suggest having your button implemented as a simple iframe. That will make it possible for you to send messages to the parent page from that button. The parent page, however, has to be ready to listen to those messages and add to cart whatever ids you specify. So the client devs will have to do some implementation for this to work.
Well, no, this is a bit too much to ask for. You can ask the merchant to share that data with you so that you could improve your algos (tune them for the client) and, therefore, improve the merchant's conversion rates (which is a win-win scenario), but the merchant would have to actively either implement parallel tracking to your instance of analytics (install your pixel, if you're willing to develop one), or share their own data with you.
That's what a lot of very similar services do. Let's say, Facebook. Facebook sells traffic. When you buy traffic, you generally don't want to pay for irrelevant/badly converting tracking, so you're implementing so-called facebook pixel. Facebook doesn't do this implementation. Client's developers/implementation experts implement it and trigger various events through it, making it send signals to the FB endoint, indicating which client this is from, for which campaign, what the action is page load, purchase, add to cart... Just take a quick glance at FB documentation: https://www.facebook.com/business/help/402791146561655?id=1205376682832142
Facebook is just an example. There are many-many services that do similar pixels. It may be not about selling traffic, it may be about adjusting site look and feel based on AI, or generating discounts and customizing conversion funnels, or even simpler stuff like feedback chat performance and suggestions modules. All these and more exist as third parties and pretty much all of the established ones use pixels for tracking.
If you don't want to spend time at the moment to make your own tracking logic, then implementing a parallel GA tracking will be a pain for you (for your clients, actually). Instead, it would be easier to enrich their data with your products. Let's say, have them implement a product-level custom dimension that would "paint" products added to cart by you and share the data with you.
Note that a client who goes for it must be a very loyal client since analytics data is normally treated as sensitive and is not readily shared with third parties, not mentioning the implementation of a custom dimension (or the using the expensive product parameters) just for a third party to count their conversions. Yes, it has to be a good friend that allows this.
Finally, you could ask them installing your GTM instance or giving you access to theirs, but that would effectively give you the power to execute arbitrary code on any of their page. I would never give a third party that power.
Tl;Dr: I would suggest making your own very simple pixel. Even though it sounds now like a lot of work, it will worth it if the project itself has real potential to be useful for ecommerce.
Exactly the same as 2.
I am using Frappe framework. I would like to share same data that is collected from Sign up to POS profile but keeping in mind that both of them located on different servers. Any advice?
You can use Event Streaming.
Event Streaming enables inter site communications between two or more
sites. You can subscribe to Document Types and stream Documents
between different sites.
For Example: Consider you have more than one Company hosted on
different sites, one among them is the main site where you want to do
ledger posting and on other sites, the Sales Invoices are generated.
You can use Event Streaming in this case. For this, your child company
sites can subscribe to the main company site for Item, Customer, and
Supplier Document Types. The main Company in turn can subscribe to the
child companies for Sales Invoices.
Source: https://docs.erpnext.com/docs/v13/user/manual/en/automation/event_streaming
I used 'com.android.billingclient: billing: 2.0.3'.
How do I distinguish between for consumable products and for products that aren't consumed?
Consumables are approved for purchase with consumeAsync() and non-consumable products are approved for purchase with acknowledgePurchase().
It seems like consumable products and non-consumable products are classified through whether consumeAsync() is called or not.
1. Are there other methods of classification?
(https://developer.android.com/google/play/billing/billing_library_overview#acknowledge/)
2. acknowledgePurchase () is directed to apis for non-consumable products. Shouldn't it be used for consumable products?
I can add a developer paylaod this way:
For consumable products, consumeAsync() takes a ConsumeParams object that includes a developer payload field, as shown in the following example:
BillingClient client = ...
ConsumeResponseListener listener = ...
ConsumeParams consumeParams =
ConsumeParams.newBuilder()
.setPurchaseToken(/* token */)
.setDeveloperPayload(/* payload */)
.build();
client.consumeAsync(consumeParams, listener);
For products that aren't consumed, acknowledgePurchase() takes an AcknowledgePurchaseParams object that includes a developer payload field, as shown in the following example:
BillingClient client = ...
AcknowledgePurchaseResponseListener listener = ...
AcknowledgePurchaseParams acknowledgePurchaseParams =
AcknowledgePurchaseParams.newBuilder()
.setPurchaseToken(/* token */)
.setDeveloperPayload(/* payload */)
.build();
client.acknowledgePurchase(acknowledgePurchaseParams, listener);
(https://developer.android.com/google/play/billing/billing_library_overview#attach_a_developer_payload)
3. Do you plan to add management type for consumable and non-consumable products in the future?
4. Could the call be restricted for mistyped functions?
Google Play doesn't have the knowledge of consumable SKUs vs non-consumable SKUs. Only developers have this knowledge.
If you would like users to repeated purchase one SKU (like coins, gems), then you can call consumeAsync() to remove it from user's library. Google Play won't allow users to repurchase a SKU if it is already in his library. Therefore, you have to consume it (remove it from his library).
For some other SKU, such as subscription or ads free, premium content unlock, limited item, if you want users only buy once then don't consume it. Instead, use acknowledgePurchase API. Google Play introduced this as a contract to make sure that you have granted the products to users.
Therefore, I would say keep a catalog of consumable, non-consumable SKUs on your side. And based on the type, call the correct Google's API.
For what I understand so far,
non-consumable product call acknowledgePurchase() is to set the purchase record to acknowledged in Google side, so when u trying to trigger queryPurchase(), it will show the product is purchased with acknowledged (parse the json data to view the data)
consumable product call consumeAsync() is to remove the data in Google side. So when trigger queryPurchase() should be no record for that.
Why consumable product can purchase again?
Because the record ady removed from the record. When trigger purchase again will not return error code 7 (BILLING_RESPONSE_RESULT_ITEM_ALREADY_OWNED)
both consumeAsync() and acknowledgePurchase() also will set the payment to done. If didn't trigger anyone of them, then it will auto refund after 3 days. Both of the action also work as acknowledge the payment.
So for your question
1. Are there other methods of classification?
Those acknowledged one should be non-consumable product, since consumable product record should be removed after success record to our side. Or if want to classify, maybe can set developer payload for the acknowledgement(can't changed after set)
2. acknowledgePurchase () is directed to apis for non-consumable products. Shouldn't it be used for consumable products?
no, use it separately based on your requirement
The answer maybe incorrect. Just some sharing about it.
welcome to answer my question also related to this, acknowledgement perform at server side
Server side can do something similar to mobile side comsumeAsync() in Google Billing Library?
I want to solve an everyday problem:
My friends and I meet and they order beer and pizza and one person pays for everything. The day after, the paying person should get their money back via Paypal. My goal now is to create a form where each person can choose whether he has used pizza, beer or both and send the corresponding price via Paypal.
I am quite able to write a small web application that solves this problem, but I wanted to look for other options.
First I came across google forms with script app. But there is no possibility to edit the answer to the form.
Next I thought of a simple spreadsheet that lists the different possibilities with a Paypal button where the receiver and price is adjusted.
My question here is:
Can one create a Paypalbuttton without JS or PHP, where the price and or receiver are changed?
In general I would like to hear your ideas on this topic.
Yours sincerely,
J gallus
I have tried this and with only clinet side integration(i assume you are focusing only client side integration) you can only dynamically change the amount but not the receiver/ payee. In only client side interation its not possible and you may end paying multiple transaction fee with this approach. you may look into this PayPal Split pay
or use vemno payment option. what you really need is an peer-to-peer payment model.
Assume there are two services,
Product Service
Coupon service
Coupon is tagged against the product. And when the coupon is changed for any product there is an API call from product service to the coupon service which calculates the coupon discount and sends back to the product service. And product service maintains that cache. However, To calculate the discount, coupon service need the product information such as product category, SKU type etc. and discount varies based on that so there is again an API call to the product service making it cyclic call. There are a couple of solutions,
maintain product cache at the coupon service. - This is an overhead as we need to maintain the cache on every product field update and this is not the solution we are looking for.
When product service makes an API call to the coupon service, send all the fields it needs - There is tight coupling in this approach.
What is the correct way to solve this problem?
If you have decided that you need 2 different services for this, I would agree that a cyclical dependency is kind of bad and worth trying to remove.
However, I don't really see it being needed here. I think the "coupon" service needs to be aware of the "product" service, but not vice versa.
The issue you are having though is that your coupon service needs to respond to a change that's happening on the product service. Right now you solved this by having the product service send a message to the coupon service.
Some possibilities to fix this include:
Have the coupon service occasionally poll for updates.
Deploy a pub-sub system. Make a 'product change' something you can subscribe to and have the coupon subscribe to that.
I would suggest a third option though. It sounds to me that a 'coupon change' as a concept should not at all exist in the product service. Why does it? It sounds like you actually might have 3 different services:
Product information
Coupon information
Cart