[BUG] [Coinbase]: declares manual capture and a refunds webhook flow that the connector does not implement

Bug Description

The Coinbase connector declares capabilities its flows do not implement. The declarations are what GET /feature_matrix reports, so the generated capability tables (including the connector docs page) advertise capture methods and a webhook flow that cannot work.

Two mismatches, both at crates/hyperswitch_connectors/src/connectors/coinbase.rs:

1. Capture methods. The supported payment methods declare three capture methods (L475-478):

let supported_capture_methods = vec![
    enums::CaptureMethod::Automatic,
    enums::CaptureMethod::Manual,
    enums::CaptureMethod::SequentialAutomatic,
];

But the capture flow is a stub (L349-361):

impl ConnectorIntegration<Capture, PaymentsCaptureData, PaymentsResponseData> for Coinbase {
    fn build_request(...) -> ... {
        Err(errors::ConnectorError::FlowNotSupported {
            flow: "Capture".to_string(),
            connector: "Coinbase".to_string(),
        }.into())
    }
}

A payment created with capture_method: manual or sequential_automatic fails at capture time with FlowNotSupported. Only automatic capture works, since it needs no capture call.

2. Refund webhook flow. The declared webhook flows include refunds (L496-497):

static ref COINBASE_SUPPORTED_WEBHOOK_FLOWS: Vec<enums::EventClass> =
    vec![enums::EventClass::Payments, enums::EventClass::Refunds,];

There are no refunds on this connector to report on. ConnectorIntegration<Execute> returns FlowNotSupported (L365-377), and the payment method declaration itself sets refunds: FeatureStatus::NotSupported (L487). get_webhook_event_type (L427-448) recognizes only charge:confirmed, charge:resolved, charge:failed, charge:pending and charge:created; no refund event is mapped.

Expected Behavior

Declarations match the implementation:

1. supported_capture_methods for Coinbase lists only Automatic.
2. COINBASE_SUPPORTED_WEBHOOK_FLOWS lists only EventClass::Payments.

Or, if manual capture and refunds are intended for Coinbase, the flows are implemented and the declarations stay.

Actual Behavior

/feature_matrix reports manual and sequential automatic capture, and a refunds webhook flow, for a connector that implements neither. Generated capability tables repeat both.

Steps To Reproduce

1. Call GET /feature_matrix and read the COINBASE entry: card capture methods include manual and sequential_automatic, and the webhook flows include refunds.
2. Create a Coinbase payment with capture_method: manual, authorize it, then call capture. It fails with FlowNotSupported.
3. Note that no refund can exist on the connector to produce a refund webhook: refunds are declared NotSupported and the refund execute flow is a stub.

Context For The Bug

Found while regenerating connector capability blocks for the docs (juspay/hyperswitch-docs#274). The docs page carries two sentences correcting the generated table, which is the wrong end to fix it: the page should be able to state what the connector declares without contradicting it.

Same shape as juspay/hyperswitch#14242 (Bamboraapac declares SequentialAutomatic and rejects it).

This is code inspection, not an executed test.

Environment

Code inspection at main (5fb7e5598eadd8ed5fa42822427107f271a1e112); also present at 184ffd4c015fd3fea2f3868549f1a86ffa5f40da.

Have you spent some time checking if this bug has been raised before?

• I checked and didn't find a similar issue