AutoCore Payment Architecture and Providers
Maps payment orders, attempts, provider adapters, editions, and activation boundaries.
Payment orchestration keeps the order and attempt state in AutoCore, while provider adapters own hosted checkout, provider verification, and provider-specific reconciliation. Provider availability is edition-aware and credential/configuration-gated.
Release candidate source
This article reflects the audited AutoCore source revision 7a504f6e430c16d4fcb03ebdea3cc3fb7816df60 and immutable release-candidate tag v1.0.0-rc.1 at 9edfb109f44cc80385784c694b96392cfc04e70f. Configuration and external provider behavior remain deployment-dependent.
Source boundary
| Control | Source-verified behavior |
|---|---|
| Providers audited | Five descriptors are present: mock, iyzico, PayTR, Stripe, and PayPal. |
| EskişehirAraba | The registry permits mock and iyzico; mock is local/test only and iyzico is sandbox-bound in the reviewed source. |
| AutoCore | The registry permits mock, Stripe, and PayPal; live operation remains safety-locked until explicit configuration. |
| PayTR | The descriptor is present for compatibility but the provider is disabled and has no active implementation. |
Operational controls
Use the smallest verified control for the task. Keep provider, host, legal, and operator responsibilities separate from application behavior. When a control is not implemented or not verified, leave it disabled or mark it as a limitation.
Verification
Verify the route, relevant API or configuration state, negative path, audit/evidence result, and public effect before closing the task. Record unknown or configuration-dependent behavior as a limitation.