pub struct Capabilities {
pub separate_capture: bool,
pub partial_capture: bool,
pub partial_refund: bool,
pub repeated_refund: bool,
pub lookup_by_order: bool,
pub resume_by_continuation: bool,
pub saved_instruments: bool,
}Expand description
What a provider will do, asked before there is a payment to ask it about.
This and ErrorKind::Unsupported answer
different questions and both have to exist. This one is for planning: a
checkout deciding whether to offer authorise-now-capture-later needs the
answer before it has a payment. Unsupported is for enforcement, and stays
the thing that actually refuses the call.
A capability that says yes and a call that then fails is a bug in the adapter, and so is the reverse. An adapter’s tests are where that is held to.
Every field is public and the struct is open, for the same reason
Charge is: an adapter in someone else’s repository has to be able to
build one.
Fields§
§separate_capture: boolFunds can be held at authorisation and taken later by
Provider::capture.
False says the provider takes the money at authorisation and has no capture step — not that capture failed. Distinguishing those two is the whole reason this type exists.
partial_capture: boolProvider::capture accepts an amount below the one authorised.
Only meaningful where separate_capture is true.
partial_refund: boolA payment can be refunded for less than it was captured for.
repeated_refund: boolA payment can be refunded more than once, up to what was captured.
lookup_by_order: boolProvider::lookup can answer what became of a request keyed by the
caller’s own reference.
What a crash-recovery path reads before it decides between asking and calling again. False does not mean the provider forgot the reference — it means this adapter has no call that finds a payment by it, so a caller whose request timed out has nothing to ask and must rely on whatever idempotency the provider offers instead.
resume_by_continuation: boolProvider::resume can read back a flow by the token
NextAction::Redirect handed over,
without the payment ever having been named.
What a caller reads when the payer comes back from a hosted form. False
does not mean the flow cannot be finished — it means the provider named
the payment when it opened the flow, so
Provider::charge_status is what finishes it and the continuation is
not needed. True is the case that has no payment id yet at all.
saved_instruments: boolAn instrument Provider::instruments lists can be charged, through a
call of this adapter’s own — with the payer entering nothing.
What a checkout reads before it offers “use my saved card”. This
describes charging, not listing: every adapter answers
Provider::instruments regardless of this flag, and the two do not
have to agree. PayTR’s hosted form does store a card — a vault exists —
but nothing here can list it or charge it, so both answer
ErrorKind::Unsupported, for two
different reasons that happen to give the same result: false here
says specifically that this adapter has no call that charges one, which
is the answer a checkout needs before it offers the button.
The charging call itself is the adapter’s own: it needs what that
provider demands around a saved-instrument payment, which is not the
same list twice at any two of them, and neither Provider::charge
nor Provider::instruments carries any of it.
Trait Implementations§
Source§impl Clone for Capabilities
impl Clone for Capabilities
Source§fn clone(&self) -> Capabilities
fn clone(&self) -> Capabilities
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more