When something happens in your shop, Shopify sends a message about it to your
memberarea. Each of those messages is called a delivery, and every one is
recorded, whether it worked or not. Open your Shopify page at
/admin/settings/integrations/shopify, then the Webhook log tab.
What a row shows
| Part of a row | What it says |
|---|---|
| Topic | What happened in the shop: orders/paid, orders/cancelled, refunds/create, customers/create, customers/update, customers/delete, products/update, products/delete or app/uninstalled. Shopify's three privacy topics land here too. |
| Note | One line under the topic, saying what we did with the delivery. If it failed, the error stands there instead. |
| Result | The badge on the right. |
| Details | Click the row to open it: order number, email, amount, currency, the Shopify id, the number of attempts and the full error. |
Twenty-five deliveries fit on a page, newest first.
The four results
Processed means we did the work. For a paid order that means the order was created and the mapped access granted. A paid order for a product nobody mapped is processed too: the note reads "no mapped item", the order exists here, and nothing was unlocked.
Ignored means we understood the delivery and deliberately did nothing. The note says why: the shop is not linked to a workspace, or a product changed that no mapping points at. A paid order does not land here just because nobody mapped the product, that case counts as processed. If you sell physical goods next to courses, those orders still arrive here and still become orders in your memberarea. They unlock nothing.
Pending means the delivery arrived and is waiting its turn. It should not stay pending for more than a few seconds. If many rows sit at pending, something on our side has stalled. Write to support@memberarea.io.
Failed means something went wrong. The note carries the reason in plain words, and the row offers a button to run it again.
Run a failed delivery again
Press Process again on the row. The button is only there for a delivery that failed or has not been processed yet, so a row that already counts as processed or ignored carries none. The delivery is queued again with the payload Shopify originally sent, so running it again after you fixed the cause does the real work, not a stripped-down version of it.
A delivery is only ever acted on once. Every delivery carries an id from Shopify, and the same id never creates a second order or a second grant, no matter how often it is processed again.
Filter while hunting
The buttons above the list narrow it to Processed, Ignored or Failed, and All brings everything back. When a customer reports a missing course, filter to Failed first, then to Ignored. Between those two you will almost always find the answer.
Reasons you will actually see
| Note | What to do |
|---|---|
| This product is not mapped | A product changed in the shop that no mapping points at. Nothing to do unless you meant to map it. |
| Shopify rejected the access token | Reconnect the shop, then press Process again. |
| This app is missing a permission | Reconnect the shop so it can ask for that permission again. |
| Shopify is rate limiting this shop | Nothing. It retries itself with growing pauses. |
| Refund recorded, the refunded items were not mapped | The refund is for a product that was never mapped, so there was no access to take back. |
What is kept
We keep every delivery with the data Shopify sent, so processing one again does the real work. That data is about your customers, so we store it encrypted.
When Shopify sends a deletion request for one of your shop customers, we remove the link to that customer and every customer delivery we hold about them. The member in your memberarea stays: they are your contract partner, not ours, and they may have bought from you elsewhere too.