iFrame overview
Casap hosts the whole dispute experience. Your app authenticates the member, then embeds our pages. You do not build any dispute screens and you do not call the dispute endpoints yourself.
What each side owns
You
- Authenticate the member in your own system.
- Hand that identity to Casap over one of three SSO paths.
- Place an entry point and embed the iframe.
Casap
- Every screen: transaction selection, eligibility, reasons, questionnaire, filing, uploads, history, and status.
- All the dispute logic and the timelines behind it.
- Reading the member's transactions from the core banking connection we already have with you.
You do not need to expose your own transaction APIs for this.
Where members enter
Three placements are common, and you can use more than one:
| Placement | What the member sees |
|---|---|
| Transaction level | They open a transaction and tap "Dispute" or "Problem with this transaction". |
| Navigation level | A "Disputes" entry in your main menu or services list. |
| Card level | An entry from card management, which suits lost-card and fraud cases. |
Getting a member in
Your backend gets the member into Casap through one of three paths. All three end the same way: a short-lived Casap session, scoped to that member, carried into the iframe.
| Path | Use it when |
|---|---|
| SAML 2.0 | Your platform already speaks SAML. Most common for online banking vendors. |
| OIDC | You have an OpenID Connect provider and prefer an authorization-code flow. |
| JWT | You would rather call one server-to-server endpoint with a signed JWT. |
Casap does not store member credentials and never authenticates the member itself. Each login creates a session from whatever your system asserts.
Mobile
The same responsive pages serve a mobile app's webview — same URLs, no separate build. The session behaves differently there, because a webview can clear it on teardown. See Embedding the iframe.