← library
Self-serve ID; pay gate
Identity / payments·agent-generated · deepseek-v4.1-flash·checked 2026-10-28

Amazon Payments (Login with Amazon / Amazon Pay)

pay.amazon.com/ ↗
difficulty
2/5

Login with Amazon OAuth is live and self-serve (security profile + privacy URL, ~20–30 min); Amazon Pay money movement is a separate merchant onboarding gate not detailed in these sources.

First working connection
~20–30 minutes
Production / approved
LWA: no approval wait; Amazon Pay: unknown, est. days–weeks
Composio managed OAuth
Bring your own app
Not in Composio's managed-OAuth list — you'll need your own OAuth app (or it isn't a Composio toolkit yet).
who does itagent 4you 4provider 0
evidencetested 5sourced 31inferred 8
◆ agent run9 pages read25/29 quotes verified verbatim55s$0.025deepseek-v4.1-flash

01Pick your path

Login with Amazon (identity)
when You only need Amazon sign-in, name/email, or postal code.
→ Self-serve OAuth 2.0 authorization-code flow at https://www.amazon.com/ap/oa; scopes profile, profile:user_id, postal_code. No approval wait described in fetched docs.
Login and Pay with Amazon
when You need Amazon-stored payment methods on a website.
→ Combines LWA with Amazon Pay. Website-only per S1; separate Amazon Pay docs/onboarding, with extra vetting likely (inferred).
Code-Based Linking (TV/device)
when The device cannot launch a web browser.
→ Display a user code and verification URL; add a device client under the same security profile. Extra device settings.

02Time & effort

Hands-on work
50 min – 1.9 h
Waiting on others
3 days – 3 weeks
You're actually working
<1% of elapsed time
Phases
6
start↑ first working connection, then production pathproduction
  1. DEVCreate developer account + security profile5–15 minutessourced[S3][S5]Free account; consent privacy URL is required.
  2. DEVConfigure website client + redirect URI5–10 minutessourced[S2][S3]Copy Client ID and Client Secret; keep the secret server-side.
  3. DEVImplement authorize + token exchange10–30 minutessourced[S2]Agent can draft the code; you add real credentials.
  4. DEVTest consent, refresh, logout10–20 minutessourced[S2][S9]You must click through Amazon consent with a real account; agent can script token tests.
  5. PRODProduction hardening20–40 minutessourced[S2][S9]No LWA production review is described in the fetched docs.
  6. PRODAmazon Pay merchant onboarding (if needed)wait 3–21 dayssourced[S1]Duration inferred; not part of LWA OAuth. Could be longer or shorter.
agent can do it you waiting on providerbar widths ∝ √time, so short tasks stay visible

03Steps

0/8 done

Get a working connection

  1. Open the LWA console and sign inyousourced ❝[S5][S4]

    Go to the Login with Amazon console. First-time users create a free Amazon Developer account.

    “If this is your first time using the Developer Console, you will be asked to set up an account.” — [S5] verified verbatim
    ↗ developer.amazon.com/loginwithamazon/console/site/lwa/overview.html
  2. Create a Security Profileyousourced ❝[S5][S3]

    Click Create a New Security Profile. Enter Name and Description. The Name appears on the consent screen. You must supply a Consent Privacy Notice URL; logo is optional.

    “You must enter a Consent Privacy Notice URL for your application.” — [S5] verified verbatim
    ↗ developer.amazon.com/loginwithamazon/console/site/lwa/overview.html
  3. Add website settings and copy credentialsyousourced ❝[S3][S2]

    Add the website/app to the profile. Register the HTTPS redirect URI you will use. Copy the Client ID and Client Secret; the secret must stay server-side.

    “The Authorization Grant uses the client identifier, but the Authorization Code Grant requires both the client identifier and client secret.” — [S3] verified verbatim
  4. Build the authorization requestagentsourced ❝[S2]

    Send the browser to https://www.amazon.com/ap/oa with client_id, scope, response_type=code, redirect_uri, state, code_challenge, and code_challenge_method=S256. Use only the scopes you need.

    “To request authorization, the client (website) must redirect the user-agent (browser) to make a secure HTTP call to https://www.amazon.com/ap/oa with the following parameters.” — [S2] verified verbatim
    ◆ prepared by agent · Authorize URL template
    https://www.amazon.com/ap/oa?client_id=YOUR_CLIENT_ID&scope=profile%20postal_code&response_type=code&redirect_uri=https%3A%2F%2Fyourapp.example%2Fcallback&state=RANDOM_STATE&code_challenge=BASE64URL_SHA256(CODE_VERIFIER)&code_challenge_method=S256
  5. Exchange the code server-sideagentsourced ❝[S2]

    POST grant_type=authorization_code, code, redirect_uri, client_id, and client_secret to https://api.amazon.com/auth/o2/token (or the EU/FE endpoint). The code expires in 5 minutes.

    “An authorization code is valid for 5 minutes.” — [S2] verified verbatim
    ◆ prepared by agent · Token exchange curl
    curl -X POST https://api.amazon.com/auth/o2/token -d grant_type=authorization_code -d code=AUTH_CODE -d redirect_uri=https://yourapp.example/callback -d client_id=YOUR_CLIENT_ID -d client_secret=YOUR_CLIENT_SECRET
  6. Mark scopes essential vs voluntaryagentsourced ❝[S7][S8]

    Use scope_data JSON to make only business-critical scopes essential; leave postal_code voluntary unless required. This changes what users can uncheck on consent.

    “This information is specified using the _scope\_data_ parameter in the authorization request.” — [S7] verified verbatim

Make it production-ready

  1. Persist refresh token and implement refreshagentsourced ❝[S9][S2]

    Refresh tokens start with Atzr|, are valid until the user revokes access, and are only returned in the authorization-code grant when client_secret is supplied. Do not expose them to browser apps.

    “Refresh tokens are returned only in the Authorization Code Grant.” — [S9] verified verbatim
  2. Evaluate Amazon Pay separatelyyouinferred[S1]

    If you need payments, review Amazon Pay docs. Amazon Pay is website-only per S1; these sources do not document payment scopes, merchant vetting, or approval time.

    ↗ pay.amazon.com/

04Requirements, scopes & nuances

You'll need

  • ▸Free Amazon Developer account; first-time LWA console users must set one up. sourced ❝[S5][S4]
  • ▸Security profile enabled for Login with Amazon. sourced ❝[S3][S5]
  • ▸Consent Privacy Notice URL published and entered in the security profile. sourced ❝[S5][S3]
  • ▸HTTPS redirect URI registered and used consistently. sourced ❝[S2]
  • ▸Client ID plus client secret for the authorization-code grant. sourced ❝[S3][S2]
  • ▸PKCE (S256) for browser-based apps; server-side code exchange recommended. sourced ❝[S2]
  • ▸For payments, Amazon Pay is website-only in S1 and is not an LWA OAuth scope. inferred[S1]
  • ▸Manual endpoint configuration is required because discovery metadata is not published. inferred

Gotchas

  • !No OIDC/OAuth discovery metadata was served on api.amazon.com or www.amazon.com (403/404), so auto-discovery libraries will fail. inferred
  • !The authorize endpoint returns a text/html “Error Page” with HTTP 400 for an unknown client_id, not a JSON OAuth error. inferred
  • !Authorization codes expire in 5 minutes. sourced ❝[S2]
  • !Refresh tokens are only returned in the authorization-code grant and only when a client_secret is passed; browser-only apps get no refresh token. sourced ❝[S9][S2]
  • !LWA exposes only profile, profile:user_id, and postal_code — no email-only scope and no payment scope. sourced ❝[S6][S2]
  • !Amazon Pay is available for websites only; mobile app payment use is not supported per S1. inferred[S1]
  • !The consent screen requires a privacy policy URL; missing it blocks security-profile setup. sourced ❝[S5][S3]
  • !Seller Central App Console is deprecated; existing LWA apps need account linking or migration. sourced ❝[S1]
Scope / permissionTierNoteEvidence
profilebasicName, email, and Amazon account ID. Broadest LWA identity scope.sourced ❝[S6]
profile:user_idbasicAmazon account ID only; narrowest identity scope.sourced ❝[S6]
postal_codesensitiveZIP/postal code from the Amazon account; request as voluntary unless essential.sourced ❝[S6][S8]

05If you get blocked

✕Existing LWA app is registered in the deprecated Seller Central App Console.sourced ❝[S1]

→ Use account linking or contact lwa-migration-support@amazon.com; client ID and secret remain unchanged.

✕OIDC/OAuth client library cannot auto-discover endpoints.inferred

→ Hardcode the authorize endpoint https://www.amazon.com/ap/oa and token endpoint https://api.amazon.com/auth/o2/token (or the EU/FE endpoint).

✕Browser-only app needs a long-lived session but gets no refresh token.sourced ❝[S2][S9]

→ Add a server-side code exchange that supplies client_secret, then store the returned refresh token server-side.

✕You need to accept payments, not just log users in.inferred[S1]

→ Use Amazon Pay separately; LWA only identifies the user. Amazon Pay is website-only per S1 and has separate onboarding.

✕Security profile creation is blocked by a missing privacy notice URL.sourced ❝[S5][S3]

→ Publish a privacy policy over HTTPS and paste the URL into the Consent Privacy Notice URL field.

✕Redirect URI mismatch or non-HTTPS URI.sourced ❝[S2]

→ Use the exact same HTTPS redirect_uri in the authorize request and the token exchange.

06Evidence: what was tested, sourced, and still uncertain

$ probes: live GETs with a dummy client_id, no credentials
✓ Discovery document (/.well-known/openid-configuration) → 403
https://api.amazon.com/.well-known/openid-configuration
not published
∴ No public OIDC discovery on the token/API host; do not rely on issuer discovery.
✓ Discovery document (/.well-known/oauth-authorization-server) → 403
https://api.amazon.com/.well-known/oauth-authorization-server
not published
∴ No RFC 8414 metadata on the API host; configure endpoints manually.
✓ Discovery document (/.well-known/openid-configuration) → 404
https://www.amazon.com/.well-known/openid-configuration
not published
∴ No OIDC discovery on the consumer host.
✓ Discovery document (/.well-known/oauth-authorization-server) → 404
https://www.amazon.com/.well-known/oauth-authorization-server
not published
∴ No OAuth server metadata on the consumer host.
✓ Authorize endpoint with a fake client_id → 400
https://www.amazon.com/ap/oa?client_id=probe_invalid_client&response_type=code&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
text/html;charset=UTF-8 — body mentions "Error Page"
∴ Authorize endpoint exists and validates client_id, but returns an HTML error page, not JSON; test with a real client and handle non-JSON errors.

Still uncertain

  • ? Amazon Pay merchant onboarding requirements, supported countries, fees, and approval times are not in the fetched sources; the days–weeks estimate is inferred.
  • ? The fetched LWA docs describe self-serve registration but do not state whether any production or distribution review exists for web apps.
  • ? Access-token lifetime is not stated; only authorization-code lifetime (5 minutes) and refresh-token validity (indefinite until revoked) are documented.
  • ? The exact redirect-URI registration UI and limits are not shown in the fetched pages.
  • ? The 403 discovery responses may be bot protection rather than definitive proof that no metadata exists; recheck with a browser/real client.
  • ? Whether Amazon Pay uses additional OAuth scopes or entirely separate payment APIs is not documented in these sources.
  • ? Generated automatically; no app was registered and no review was submitted.