When a billing payment destination is not ready for appliance repair businesses

A payment destination can be present but unusable, attached to the wrong organization, or still waiting for provider verification. Check identity and readiness before assigning it to a rule, and keep credentials out of operational notes.

Find your symptom ↓

Choose the symptom you can observe

Open the matching case. Check the existing state before changing a record or repeating an action.

The destination is missing from the billing setup view.

Check first

  1. Confirm the organization and role used to view the destination list.
  2. Check whether the destination was saved under another organization or is still pending setup.
  3. Compare the destination display name and non-secret account identifier with the setup request.

Next action

Correct the organization or access context, or route the missing destination to the authorized setup owner. Do not create a second destination until the first record's state is understood.

Confirm the result

The intended organization shows one destination record with a readable account identifier, lifecycle state, and owner.

The rule routes to a different destination than the team expected.

Check first

  1. Compare the rule version's selected destination with the organization's standard or fallback route.
  2. Check whether an older active rule version still governs the selected period.
  3. Confirm the displayed destination belongs to the intended organization and scope.

Next action

Resolve the route precedence with the billing owner, then update the applicable rule version or default through the authorized setup path. Keep the previous route visible for periods it already governed.

Confirm the result

A representative rule and period show the intended destination and the readiness check identifies no route ambiguity.

The destination remains pending verification.

Check first

  1. Read the current verification state and the provider-neutral reason it is pending.
  2. Check whether required account metadata, permissions, or callback setup is incomplete.
  3. Confirm the destination is not being used by a live rule while it is unready.

Next action

Complete the missing setup with the authorized account owner, then recheck the destination state. Keep affected rules unready until the provider status is confirmed; do not paste secrets into the troubleshooting record.

Confirm the result

The destination has a current ready or explicitly blocked state, and any assigned rule reflects that state before processing.

A destination update appears to save but billing still reports the old state.

Check first

  1. Compare the destination update time with the rule and readiness timestamps.
  2. Refresh the destination detail and verify the saved non-secret account metadata.
  3. Check whether the rule points to a different destination record or version.

Next action

Reconcile the destination and rule references with the setup owner, then recheck readiness from the intended rule. Do not repeat credential changes while the record relationship is unclear.

Confirm the result

The destination detail, rule configuration, and readiness result identify the same current destination and state.

Prepare a useful escalation

  • Include organization scope, destination display name, non-secret account identifier, current state, rule reference, and timestamps.
  • Never include full provider credentials, private keys, or authentication tokens in the incident record.
  • Route provider verification or permissions questions to the authorized account owner.

Reference the relevant record instead of copying credentials or unrelated personal information into the handoff.

Capture your findings

Entries stay in this page and are not sent to Granite. Download a copy before leaving.

Continue in Granite

Granite's payment destinations workspace connects permitted Stripe accounts to billing rules and readiness.