Stripe Refund Approval Workflow

Overview

FlowLibs - Stripe Refund Approval Workflow (CF-730) adds a governed approval gate to Stripe refunds. On a schedule it polls a Dataverse refund-request ledger for new Pending requests, validates each original charge in Stripe, routes an amount-based approval (standard vs. senior approver), and on approval issues the refund via Stripe, writes the outcome back to Dataverse, and notifies the customer. Rejected and unvalidatable requests are recorded and routed for follow-up.

Why it matters: Unchecked refunds are a leakage and fraud risk. An approval gate with charge validation controls refunds while keeping small amounts fast, and the Dataverse ledger gives finance a complete, auditable record of every decision.

Built API-first as a Dataverse workflows (cloud flow) record. Ships Off — going live requires only authorizing the three connections and setting the env var values (Stripe key, approver emails, threshold). Flow Checker: 0 errors / 0 warnings.

Use Case

Finance wants every customer refund approved per policy and then executed automatically, with a durable audit trail. Intake systems (a form, a Teams request, or an agent) drop refund requests into a Dataverse ledger table; this flow processes the queue: it confirms the charge is real and refundable, gets the right person to approve based on the refund amount, issues the refund, and closes the loop with the customer.

Flow Architecture

Environment Variables

Connectors & Connections

Connector	API name	Actions used
Microsoft Dataverse	shared_commondataserviceforapps	ListRecords UpdateRecord
Approvals	shared_approvals	StartAndWaitForAnApproval
Office 365 Outlook	shared_office365	SendEmailV2
HHTTP	http	GET /charges/{id} POST /refunds

Note — All connections are referenced as solution connection references; the flow is portable between environments as long as a connection is mapped at import time.

Customization Guide

Almost every realistic variant of this flow can be implemented by changing environment variable values. A few cases require small edits inside the flow definition — those are called out explicitly below.

Approval tiers

Set Selected Approver is a single threshold today. Add more tiers (manager / director / VP) by extending the if() into nested conditions or a Switch keyed on amount bands.

Partial refunds

The refund amount comes from flowlibs_amountcents; an upstream system can request less than the original charge. Add a guard comparing it to the charge's amount minus amount_refunded to prevent over-refunding.

Reason-based routing

Route by flowlibs_reason (e.g. fraud → senior, duplicate → auto) alongside amount.

Auto-approve floor

Short-circuit the approval for trivial amounts (skip Start Refund Approval when amountcents is below a small floor) to keep low-value refunds instant.

Idempotency

The Stripe refund POST stamps metadata[correlation_id]; add a Stripe idempotency key header for safe retries.

Key Expressions

The flow is intentionally light on Power Fx / WDL gymnastics — the heaviest expressions are the branch-name concatenation and the approval outcome check. They are listed below in the order they appear in the flow.

@if(greaterOrEquals(int(items('Apply_to_each_Request')?['flowlibs_amountcents']), variables('varThresholdCents')), variables('varApproverSenior'), variables('varApproverStandard'))

@and(equals(body('Get_Stripe_Charge')?['refunded'], false), equals(body('Get_Stripe_Charge')?['status'], 'succeeded'))

charge={id}&amount={amountcents}&metadata[correlation_id]={correlationId}

@string(div(int(items('Apply_to_each_Request')?['flowlibs_amountcents']),100))

@first(outputs('Start_Refund_Approval')?['body/responses'])?['comments']

Customize & download