Struct RefundRequest 

#[non_exhaustive]
pub struct RefundRequest {
    pub payment: PaymentId,
    pub amount: Option<Money>,
    pub reason: Option<RefundReason>,
    pub idempotency_key: Option<IdempotencyKey>,
    pub customer: Option<Box<str>>,
    pub return_url: Option<Url>,
    pub metadata: BTreeMap<String, String>,
}

A refund to make.

Build one with RefundRequest::builder.

Two of these fields are here because one provider needs them and the others ignore them, which is the same reason ChargeRequest::customer exists: iyzico’s In-Store API wants a userId and a callback address on a refund exactly as it does on a payment, and a refund request with nowhere to put them would mean that adapter could never implement this trait method.

Fields (Non-exhaustive)

Non-exhaustive structs could have additional fields added in future. Therefore, non-exhaustive structs cannot be constructed in external crates using the traditional Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.

payment: PaymentId

The payment to take the money off.

amount: Option<Money>

How much to give back, or None for all of it.

None is not universally answerable. Mollie and iyzico’s classic API have no “refund what is left” request — both take an amount and only an amount — so their adapters say what they do with None on their own refund, and one of the two costs an extra request to find the figure out. See Provider::refund for the table.

reason: Option<RefundReason>

What to tell the provider the money went back for.

idempotency_key: Option<IdempotencyKey>

A key that makes replaying this refund safe.

Worth more here than on a charge. A replayed charge opens a second payment somebody can see and cancel; a replayed refund gives the money back twice, and the second one is the shop’s. A provider that cannot honour a key ignores it rather than refusing the call, and says so on its own refund.

customer: Option<Box<str>>

The payer, in the provider’s own terms, where the refund needs naming them again.

iyzico’s In-Store userId. Everywhere else this is ignored: the payment already knows whose it was.

return_url: Option<Url>

Where the provider should send the payer back to, where a refund needs their agreement.

iyzico’s In-Store refund posts its outcome here, the same way its payment does. Everywhere else this is ignored.

metadata: BTreeMap<String, String>

Key/value pairs handed to the provider and given back unchanged.

Implementations

impl RefundRequest

pub fn builder(payment: PaymentId) -> RefundRequestBuilder

Starts building a refund.

Trait Implementations

impl Clone for RefundRequest

fn clone(&self) -> RefundRequest

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for RefundRequest

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.