Payments and Gateway

This standard governs payment method settings in the content management system and the handling of payment credentials. It is used by the Web Administrator, who maintains payment method settings; by the Finance function, which owns payment credentials and their rotation; and by Front Desk staff, who recognise and report payment failures. Payment configuration is split in two, deliberately: credentials are held where only the Company's infrastructure can reach them, and business settings are held where an authorised manager can reach them. The two shall never be mixed. Customer payment obligations are governed by the Payment Terms; this standard states how the console is operated, and does not restate them.

Roles and duties

• Finance function: owns payment credentials, performs rotations, and confirms a live test transaction after every credential change.
• Web Administrator: maintains which payment methods are active and their configuration, through the gateway settings action only.
• Front Desk: reports payment failures with the booking, the time, and what the customer saw, and never attempts to reconfigure settings for a single declined card.

The two halves of the configuration

Credentials: secret keys, publishable keys, and webhook signing secrets for the payment processor: are held as protected infrastructure secrets, managed outside the console. They are never stored in the database, never appear in the console, and shall never be pasted into chat, documents, email, or tickets. A credential that appears anywhere outside its protected store shall be treated as compromised and rotated immediately.

Business settings live in the payment methods store, maintained through the gateway settings action in the console. Each method is identified by a code (card payment is the current method) and carries an active switch and a configuration record. Activating a method offers it at checkout; deactivating it removes it from checkout. That is the entire settings surface: which methods are offered, and their configuration. Status displays elsewhere in the admin console: connection state, terminal reader status, fee and payout schedules: are readouts for information, not settings to edit.

What the settings control

The Web Administrator shall attend to three matters in the configuration

1. Active methods. Only methods the business intends to accept shall be active.
2. Deposit behaviour for bookings. Whether the deposit is captured at booking time or authorised at booking and captured at the appointment. Capture is simpler to operate; authorisation is friendlier to the customer. The choice is the Finance function's, recorded in the configuration.
3. Notification health. Payment notifications from the processor are how the system learns a payment succeeded. If notifications stop arriving, payments sit in pending. After any gateway change, the Finance function shall confirm that money is actually flowing: a completed test transaction and its notification: not merely that the method shows as active.

Credential rotation

Rotation follows this order, and the order is the control

1. Generate the new credential in the processor's console.
2. Store the new credential in the protected secret store alongside the old one.
3. Redeploy the payment functions so they use the new credential.
4. Run a live test transaction and confirm it succeeds, including its notification.
5. Only then, revoke the old credential.

Rotate first, revoke last. Revoking first breaks every checkout until the new credential is in place. Test and live credentials shall be kept visibly distinct wherever they are handled; the most expensive gateway error is test credentials in production on a busy day.

Failure modes and first responses

Operators work failures in this order: customer, configuration, processor

1. A single customer fails while others succeed. That is the customer's card, not the gateway. Do not reconfigure anything; assist the customer with another payment method.
2. Payments fail across the board after a change. Check the active switch on the payment method record first; the audit log states who changed it and when. If the method is active but charges fail, the cause is in the credential half: a rotated credential not stored, or functions not redeployed after the store changed.
3. Payments stuck in pending. Notifications are not arriving. Check the notification endpoint configuration and the processor's delivery record before changing anything else.
4. Before assuming an internal fault, check the payment processor's published service status (Stripe, under the Stripe Services Terms).

Controls

Gateway settings changes are made only by the Web Administrator role and are audit-logged with the operator and the resulting state. Credential changes are made only by the Finance function, are never recorded with their values in tickets, documents, or the audit log description, and are always verified by a live test transaction before the old credential is revoked.

Records

This standard produces payment method records and their configuration, audit log entries for each settings change, and the Finance function's rotation record: date, credential type, and verification result, never the credential value. Rotation records are retained permanently.

Escalation

A payment outage, a suspected compromised credential, or notifications failing for more than one hour goes to support@aapawz.com immediately and to the Finance function the same day. A charge dispute or legal process concerning payments goes to legal@aapawz.com.

Review cadence

The Finance function reviews active payment methods and credential age quarterly, and rotates credentials at least annually and immediately upon any suspected exposure.