# Logo e2e Fulfilment What is the most bare bones work we can do to establish e2e fulfilment for the purpose of a proof of concept? What is "proof enough"? What can we hard code... - shopperID? - tenantID - product key ## Add to cart & redirect to checkout UI // Kerrison ### In scope - no form, just a button - hard coded data as much as possible - ensure we **SET** the information required by our systems (brief ID) through the cart and receive it from the SNS event (or can make a further api call with the information we receive) Question: something about a 99d fulfiller (or if you don't specify one) ### Out of scope Additional requests to catalog for product data ## Post payment fulfilment // Radley and Melissa ### In scope - subscribe to SNS queue (probably dev tenant?) - filter messages to just the _type_ we are interested in - ensure we **GET** the information required by our systems (brief ID) through the cart and receive it from the SNS event (or can make a further api call with the information we receive) - visibly signal successful event recevied (slack notification, email, bugsnag info event) or just take a screenshot of aws monitors tab ### Out of scope - actually creating a matched project - Actually create analytics events etc? - creating a 99d "fulfiller" and associated relationship with MCP (what will happen if MCP receives orders that it doesn't have a fulfiller for?) ## Iam99 Having completed the brief, when a user attempts to purchase a product they are capable of performing logged in actions (like "claim brief") and their identity is translated between Vista and 99d such that when they land on 99d to kick off their Matched Project, they are the owner of the M.P. created from the brief. ## Catalog Having click opsed the logo-essential v2 into the PIM etc, it is possible to _create_ an order for this product via the cart ... other things?