GDPR web hooks are a required step to submitting the Shopify Payment App for approval. TLDR we need web hooks for Shopify to call that gets us to delete user's data when the user or Shopify requests it.

Documentation on the requirement here:
https://shopify.dev/apps/payments#mtls-configuration

Mandatory web hook documentation here:
https://shopify.dev/apps/webhooks/configuration/mandatory-webhooks

Some best practices for Shopify web hooks:
https://shopify.dev/apps/webhooks/best-practices

New developers should only need to run npm install when the repo is cloned. Right now this is not done for them.

right now our API generally returns two status codes

200 - good
500 - bad

we should implement more standard response codes

200 OK: The request was successful, and the response contains the requested data.
201 Created: The request was successful, and a new resource was created as a result.
204 No Content: The request was successful, but there is no response body to return (e.g., for a DELETE request).
400 Bad Request: The server could not understand the request due to invalid syntax, missing parameters, or other client-side errors.
401 Unauthorized: The request requires user authentication or the authentication credentials provided are invalid.
403 Forbidden: The server understood the request, but the client does not have permission to access the requested resource.
409 Conflict: The request conflicts with the current state of the server (e.g., duplicate resource, concurrency issues).
500 Internal Server Error: A generic server error occurred. It indicates that something unexpected went wrong on the server side.

we've been adding so many models to the repo that it's getting hard to find them, we should group these by their respective roles

We need to add linting and formatting into the main branch. Bad.

Right now there are discrete connect wallet buttons and a buy button, we should merge these into their own modal to reflect the figma designs

• once cookie is detected on login page, check if merchant onboarding is done
• if done, redirect to refund screen
• if not done, redirect to getting started
• if getting started is just completed, add in alert that usdc payments are enabled

We've identified three main APIs that we can have to populate the merchant portal.

/merchant-info
/transactions
/refunds

We should expose each route and do the following

1. Validate the JWT included in the header
2. Identify the merchant
3. Make the relevant database queries ( we can wait on this for now til the database tables get populated )
4. format the data in a flat way that can easily be consumed by the merchant portal

The fields from the response should be as follows:

/merchant-info

• name: string
• receivingWallet: string | null
• isVerified: bool
• acceptedToS: bool
• hasClosedSetUp: bool

/transactions?page=

• shopifyId: string
• date: string
• status: string
• amount: number
• tx: string
• tx_url: string

/refunds?page=

• shopifyId: string
• date: string
• status: string
• refundAmount: string
• totalAmount: string
• txUrl: string | null
• isOpen: bool

We should also include pagination query parameter as well as a total count at the top level

the query-string library is outdated and causing issues with testing, there is probably a better library to use that wont cause issues

back button currently is just an image instead of a button. it needs to be a button that redirects the customer to the cancel_url from the payment status response.

we're adding a thank you screen to the payment ui after a customer pays

we need to support geofencing on payments, we can either ingrate with an api for this or use next.js edge functions

Because of the AWS migration, it was easier to make progress by moving the transaction building code into the transaction-request serverless app.

We should move back to a package once we figure out the correct setting for turborepo for packages in our set up. This will make the transaction building code more portable and reusable as well as increase testing. It'll also by help simplifying the transaction request server.

right now we only return 200 and 500 from APIs

we should start returning correct responses for the different APIs for different reasons

So Harsha brought some things to my attention after working on merchant-ui that he feels would improve the ergonomics of the project.

• covert some specific string groups to enums
• Transactions on the merchant-ui should be named Payments and the word "transactions" should be reserved to on chain transactions
• Having dates for refund request, refund fulfillment, payment request, payment fulfillment, transaction created, transaction completed
• Change the current amounts to the amount that is being refunded and then in the response for refunds, query the payment record and include the total
• Add a new read-data handler to follow the status of a single refund record.

right now we only check transaction id's as a way to confirm payments. we should be parsing transaction contents to verify they satisfy a payment record

right now there is no specific api documentation, we should add support for open api to create docs

Shopify can pass us a currency type that a merchant is set up to support. If we're going to allow these merchants to use the app, we need to figure out how to convert that price to USDC value.

right now we have hard coded urls in the payment ui, lets create an env that hosts these and the app can access there

shopify requires we implement retrying on requests to them with an exponential backoff

Before we can submit the payments app for review, we are required to implement mTLS for all API calls to/from Shopify.

From the Payment App documentation:

"Authentication must be implemented to guarantee that traffic is secure and trusted in both directions between Shopify and your payments app. This authentication allows your app to confirm if an upstream request has originated from Shopify. Payments apps must use the Shopify CA certificate for verification."

Full documentation on requirements here:
https://shopify.dev/apps/payments#mtls-configuration

Right now we don't have the docker-compose file set up to support hot loading when files are changed and saved. This results in having to run a lengthly set of start up steps.

It would be great to support hot loading for

1. backend
2. merchant-ui
3. payment-ui

This should track all things related to the end to end Payments Flow. As a part of this flow include many things:

1. Requests received from Shopify
2. Requests out to Shopify
3. Database updates to track a payment
4. Transaction building
5. TRM Communication
6. Receiving transactions from Helius.

These should all have their own issues but this will track the connection between all of them.

Allow merchant to choose what address to refund to

make it easy to see what customer address was used to make a payment

New clones dont have a great way to run the project right away. An example .env file would go a long way here

We should have the dynamic elements show a loading state when there is no data to display

right now sentry is just on a select few apis

we need to wrap all endpoints with sentry for better logging

As part of Shopify's requirement, see internal docs for full list, we need to implement transaction monitoring into the payments app. Transaction monitoring is checking if the buyers wallet address is safe to interact with. TRM will provide us with a high level API to accomplish this. Check the 'Payment Flow' in the system design directory to see where this goes in our flow.

For now, just create a service in the backend-serverless app uses TRMs API to get a risk level, parse the response, and make sure it's under some risk level. Their docs will have the specifics. Please use axios for the networking, create a file for the response in /src/models similar to the other models, and helper methods to parse that follows a similar pattern to the other models.

Ping me if you need TRM API access or Shopify docs.

as we get closer to launch, we should have a set staging and prod environment. this will let us do development as we see fit, test changes in staging and then migrate to prod.

right now our system relies heavily on the database we are storing tx_id's into.

using tools like

1. transaction signers
2. system program account creation with key pairs generated from secrets
3. reference keys, again, possibly from secrets

we should figure out a protocol to build transactions by that would allow the party that maintains accessTokens to Shopify, which right now is us, to go back at any point in time and go from an on chain transaction to a shopify payment

Per Shopify's requirements we need to geo fence the merchant-ui and payment-ui. I think next.js has some edge functions we can use that should make this pretty straight forward. Examples of places we have to geofence are New York, China, and other sanctioned countries. We should see if we can get a deterministic list. We're able to do IP based geofencing so if locations aren't exposed through next, then we might have to find an API for this.

If we do need some kind of 3rd party API, it might make sense to create a package for this so it can be used in both apps/merchant-ui and apps/payment-ui.

Here is some info on the edge middleware from next
https://vercel.com/new/templates/next.js/edge-functions-geolocation

Here is some info on a simple ip api we could use
https://members.ip-api.com/

It might make more sense to just use the IP API if it's not too much more work so we can reuse it in the serverless-backend app

we need a way to test things locally that deal with actually querying from a database instead of mocking responses from prisma for more full testing

• likely will use the existing docker compose to stand up/down
• we should also have a set of helper methods than can pull in the large data sets and populate the database with them

shopify requires merchants to have the ability to run test payments. these should always process so we should let that happen without actually having a transaction be submitted.

We need session tokens to persist a merchants login on the frontend and to authenticate communication on the backend.

right now the QR code on the payment ui isn't functional. please make it work end to end.

right now we are openly calling into prisma from handlers and services, we should move prisma calls into their own services to abstract away this dependency.

this should also lead to better code testing but we can start here.