Amazon Processor and API
This page explains the Amazon Gift Card On Demand integration from an operations and customer-service perspective: how Amazon orders are issued, which settings control each regional brand, and what evidence to gather before escalating a failed issue or cancellation.
What Amazon does
Amazon is a synchronous processor for digital gift cards, but it is not always a single-attempt flow. The application submits an AGCOD request directly to Amazon, retries temporary RESEND responses automatically, and stores Amazon's creationRequestId as the processor reference when a code is issued successfully.
The processor is configured as:
| Property | Behaviour |
|---|---|
| Processor type | SKU_IN_ENV |
| Processing | Synchronous with automatic retry on temporary issue failures |
| Delivery | Digital code plus wrapped URL/barcode generation |
| Balance lookup | Unsupported |
| Cancellation | Supported |
| Issue success state | SUCCESS |
| Retry state | RESEND |
| Common failure examples | FAILURE, F300 / InsufficientFunds, F200 / CancelRequestArrivedAfterTimeLimit |
Order lifecycle
- A partner orders an Amazon brand and amount through the normal gift-card API.
- The processor selects credentials from
config/amazon.phpfor the current brand slug and, when present, the partner's Tillo entity override. - The issue payload uses Amazon's
CreateGiftCardoperation. It sends a generatedcreationRequestId, the AmazonpartnerId, the requested amount and currency, and the internal sale UUID asexternalReference. - If the brand config enables
sendProgramID, the payload also includes aprogramId. This is the partner's slug, but if there has been an agreement with Amazon can be overridden withprogramIdpartner attribute when one is configured. - When Amazon responds with
SUCCESS, the application stores the returnedcreationRequestIdas the processor reference, stores thegcClaimCode, formats the expiry timestamp, creates the delivery URL/barcode, and marks the card successful. - When Amazon responds with
RESEND, the processor retries automatically up to three total attempts with short backoff delays. - If all issue attempts still end in
RESEND, the issue fails and the application dispatches anAmazonCancellationjob that waits for the code to become issuable and then attempts to cancel the original Amazon request using the returnedcreationRequestIdandgcId.
!IMPORTANT Do not manually place a second Amazon order while a
RESENDcase or queued cancellation is still unresolved. The original request may still complete successfully, and a manual re-order can create a duplicate purchase.
Settings
Processor settings
The processor-level settings are environment-backed values in config/amazon.php.
| Setting | Environment variable | Purpose |
|---|---|---|
| Global throttling enabled | AGCOD_THROTTLING_ENABLED | Enables request-rate limiting for Amazon traffic |
| Global throttling request limit | AGCOD_THROTTLING_RATE_LIMIT | Maximum requests allowed in the configured period |
| Global throttling period | AGCOD_THROTTLING_RATE_PERIOD | Time window for the throttling limit |
Each supported brand slug then has its own regional AGCOD configuration, including endpoint, AWS region, and a default discountStandard credential set with accessKey, secretKey, and partnerID.
The repository currently defines separate brand entries for amazon, amazon-rewards, amazon-vb, amazon-de, amazon-fr, amazon-it, amazon-es, amazon-nl, amazon-se, amazon-usa, amazon-ca, amazon-au, amazon-at, amazon-be, amazon-pl, amazon-eb-uk, amazon-pt, amazon-ie, and amazon-rewards-ie.
Some brand entries have extra credential variants. For example, amazon-usa defines both discountStandardBackup credentials and a tilloinc credential override. The processor also checks for entity-specific credentials using the current partner's Tillo entity slug, so the same Amazon brand can route through different AGCOD accounts depending on the partner setup.
Brand settings
Amazon orders by amount rather than by a per-denomination provider SKU. The repository does not define Amazon brand-to-SKU mappings like the asynchronous processor guides do.
Brand setup still matters in three places:
- The brand slug must match the correct regional config entry so the processor uses the right endpoint, region, and AGCOD account.
- The brand's enabled denominations must allow the requested value. The original Amazon UK brand was seeded with fixed values from
£5to£100plusopen-value. - If
sendProgramIDis enabled for that brand, the partner slug is forwarded to Amazon asprogramId. If a non-empty partner attribute namedprogramIdset is forwarded to Amazon asprogramIdinstead. This supports partners that need an alternative Amazon program identifier.
Alternative programId
Use the partner attribute named programId when Amazon requires a program identifier that differs from the partner slug. The override applies only when the Amazon brand configuration has sendProgramID enabled; it is sent on the CreateGiftCard request and does not change the credentials or partnerId used for the request.
For an order using an owner with:
sendProgramID: true; and- a non-empty
programIdpartner attribute;
Amazon receives that attribute value. Without a non-empty attribute, Amazon receives the owner's slug. When investigating a program-routing issue, check both the brand's sendProgramID setting and the owner's programId partner attribute before treating the value as incorrect.
API operations
Amazon requests are JSON payloads signed with AWS Signature Version 4 and sent to the configured AGCOD endpoint. The processor uses these named operations:
| Operation | Use | Important fields |
|---|---|---|
CreateGiftCard | Issue a new Amazon gift card | creationRequestId, partnerId, value, externalReference, optional programId |
CancelGiftCard | Cancel a previously issued or pending Amazon request | Original creationRequestId, partnerId, gcId |
GetGiftCardActivityPage | Build activity-query payloads for AGCOD request history | requestId, partnerId, UTC date range, paging fields |
The processor class also defines a GetGiftCard operation constant, but the documented business flow in this repository is issue and cancel rather than customer-service balance checking.
Customer-service investigation
When an Amazon order or cancellation needs investigation, check these values in order:
- The Amazon brand slug, currency, and requested amount.
- Whether the partner's Tillo entity should have used default credentials or an entity-specific Amazon account.
- The sale UUID, which is sent to Amazon as
externalReference. - The sale's processor reference, which is Amazon's
creationRequestId. - The processor interaction audit request and response for the relevant sale.
- Whether the last issue response was
SUCCESS,RESEND, orFAILURE. - For cancellations, the original audit record's
requestIDandgcId, because the cancellation payload is built from those values rather than from the displayed gift code.
Returned gcClaimCode values are hashed before processor interaction responses are stored, so support should rely on the sale record, processor reference, and audit metadata rather than expecting to retrieve the raw code from the interaction log.
If the issue failed with F300 / InsufficientFunds, treat it as a processor funding problem rather than a customer-input problem. If cancellation failed with F200 / CancelRequestArrivedAfterTimeLimit, the repository treats that as a warning-level late-cancellation case, which means the code was already too old for Amazon's cancellation window.
Limitations and support contacts
The repository does not implement Amazon balance lookup as a customer-service operation. Cancellation is implemented, but it is time-sensitive and can return a late-arrival warning once the request is older than 15 minutes.
When escalating, include the sale UUID, processor reference, partner slug, timestamps, brand slug, and relevant request/response evidence. Do not include raw credentials, and do not assume the visible gift code in the customer journey is available in stored processor interaction logs.
Related code
app/Processors/AmazonProcessor.php— issue, cancellation, retry, credential selection, and audit logging.app/Jobs/Amazon/AmazonCancellation.php— queued cancellation recovery after repeated temporary issue failures.config/amazon.php— global throttling, regional endpoints, and brand credential sets.database/migrations/2018_03_16_163107_RCC-2572_add_issuer_attributes.php— Amazon support and commercial contacts.database/migrations/2016_08_03_091949_add_denominations_for_amazon_brand.php— original Amazon denomination setup.database/migrations/2024_01_11_092649_r_c_c-13432_update_amazon_park_processor_types.php— processor type update toSKU_IN_ENV.tests/Characterisation/Unit/Processors/AmazonProcessorTest.php— successful issue and cancellation behaviour, credential overrides, and audit expectations.tests/Feature/Processors/AmazonProcessorTest.php— insufficient-funds handling and operational logging.tests/Unit/App/Jobs/AmazonCancellationTest.php— cancellation job logging and retry flow.