> For the complete documentation index, see [llms.txt](https://city-protocol.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://city-protocol.gitbook.io/docs/neofinance-as-a-service/card-module.md). # Card Module ### Architecture Overview City Protocol's card infrastructure provides a unified interface for issuing and managing payment cards as part of our Neofinance as a Service layer. The card module is designed to abstract away provider-specific complexity, enabling integrators to build against a single, stable surface, `CityCardClient` , regardless of the underlying card issuer. Card issuance, lifecycle management, and sensitive operations like PAN reveal are all handled through a provider-backed model that keeps integration surfaces consistent and provider logic encapsulated. *** ### Key Components
ComponentDescription
CityCardClientThe primary integration surface. Provider-agnostic client that exposes a uniform API for card creation, lifecycle actions, and sensitive operations across all supported providers.
Card ProvidersEncapsulated provider modules — including ReapCardProvider, InterlaceCardProvider, and URCardProvider — that handle issuer-specific logic behind the unified client interface.
KYC PayloadIdentity verification data required at card creation. Passed directly through the creation call and forwarded to the underlying provider in accordance with its compliance requirements.
Lifecycle ActionsA set of post-issuance operations — freeze, unfreeze, reveal, and replace — that allow integrators to manage card state throughout its lifecycle. Availability varies by provider.
Meta ContextOptional metadata fields (client ID, email, OTP phone number) that allow integrators to correlate card records with their own internal user and compliance systems.