[Feature Request] Add a note (or description) field to Store Credit Account transactions

Summary

The storeCreditAccountCredit and storeCreditAccountDebit mutations currently have no way to attach a human-readable reason or label to a transaction. We’d like a note (or description) field on the transaction input so that apps can record why a store credit was issued or debited — and have that label surface on the transaction record itself.


Problem

When an app issues store credit programmatically — for example, as compensation for a return or a damaged item — the resulting transaction appears in the customer’s store credit history with no context. There is no field to write something like:

“Compensation for Order #1234 — damaged item”

As a result:

  • Merchants have no audit trail to explain individual transactions without cross-referencing an external system.

  • Support teams cannot tell at a glance whether a credit came from a return compensation, a manual goodwill adjustment, or a third-party integration.

  • Customers who see their transaction history in Customer Account pages are left with unexplained balance changes.

The current transaction object returned by the API exposes id, amount, balanceAfterTransaction, createdAt, and expiresAt, but no freeform label field.


Use Case (Concrete Example)

Consider an app that issues store credit as compensation when a customer reports a damaged or missing item. The app calls storeCreditAccountCredit after verifying the claim, but the resulting transaction record contains no indication of why the credit was issued.

Today, there is no way to attach a note such as "Compensation for Order #1234 — damaged item" to the transaction itself. The app must maintain an external mapping (e.g., in its own database) to trace a transaction back to the originating order and claim.

This means:

  1. Merchants must use our admin UI to trace a transaction back to an order — they cannot see it in native Shopify reports.

  2. If our app is uninstalled, the mapping is lost and transactions are permanently unexplained.

A note field would make the transaction self-describing and eliminate the need for this external mapping.


Proposed Change

Add an optional note string field to both mutation inputs and the transaction response type:

# Input
input StoreCreditAccountCreditInput {
  creditAmount: MoneyInput!
  expiresAt: DateTime
  notify: Boolean
  note: String          # ← new
}

input StoreCreditAccountDebitInput {
  debitAmount: MoneyInput!
  note: String          # ← new
}

# Transaction type
type StoreCreditAccountTransaction {
  id: ID!
  account: StoreCreditAccount!
  amount: MoneyV2!
  balanceAfterTransaction: MoneyV2!
  createdAt: DateTime!
  expiresAt: DateTime
  note: String          # ← new, nullable
}

Prior Art

Several other Shopify APIs already attach human-readable context to balance-related operations:

giftCardCreateGiftCardCreateInput.note / GiftCard.note

(docs)

refundCreateRefundInput.note / Refund.note

(docs)


Impact

This is a relatively small, non-breaking addition that would benefit any app that issues store credit programmatically, including loyalty programs, campaign reward apps, and return/exchange automation tools.

Hey @ogasawarakyohei You’re right - the storeCreditAccountCredit and storeCreditAccountDebit mutations do not accept a note, reason, or description field. The StoreCreditAccountTransaction fields are limited to system data like amount, balance after transaction, created time, event, and origin, so there is no custom note field to read back.

For app-created credits or debits, the transaction is represented by Shopify’s system event rather than a custom label. Order-related store credit transactions can have order-related context, but apps cannot set arbitrary text themselves.

The practical workaround is to keep that context in your app. If you need it customer-facing, you could mirror the reason, related order, amount, date, and Shopify transaction ID into app-managed customer metafields or metaobjects, then render that richer history in a customer account extension if the app has the required customer data access.

I’ve captured this gap internally as product feedback, since the audit-trail use case makes sense so thanks for raising this with us!

@Donal-Shopify Thank you for the clarification and for capturing this internally — that’s appreciated.

One concern with the metafield workaround: transaction context belongs on the transaction itself, not on the customer object. Storing it in customer metafields means our app has to own the mapping between a metafield entry and a specific transaction ID, handle cleanup on uninstall, and stay within metafield size and count limits — all to store what is fundamentally a label for a financial event. The data model is a poor fit for the problem.

To be clear about the scope of what we’re asking: a single nullable String field on the input and transaction type. Non-breaking, no impact on existing callers. The ask is intentionally minimal — we’re not looking for order-level context integration or any structured relationship. Just a plain-text note so the transaction is self-describing.

We hope this makes it onto the roadmap. Happy to provide more context if useful.

We’re also tracking a related gap: storeCreditAccountCredit and
storeCreditAccountDebit don’t support idempotency keys, which means safe
retries after network failures or timeouts require workarounds on the app
side. The community thread here captures the issue:

Together, the missing note field and the lack of idempotency leave store
credit mutations meaningfully behind other financial APIs like refundCreate
and inventoryAdjustQuantities, which support both. Happy to elaborate on
either if it helps prioritization.

Fair points on both, and the note field belonging on the transaction itself rather than mirrored into customer metafields is a reasonable critique of the workaround.

I’ve logged the note field gap as fresh product feedback with the team, and I’ve added your idempotency feedback to an existing tracked request alongside the sister thread. No timeline I can share, but both are now visible to the right team with your use case attached.

Thanks @ogasawarakyohei!

@Donal-Shopify

Thank you for taking the time to log both points and attach our use case to the relevant feedback and tracked request. We appreciate the follow-up.

If improvements for either the transaction note field or idempotency support become available, we would be very interested in adopting them in our app as soon as possible. Both would help us provide a cleaner and more reliable implementation for merchants.