Know what you’re authorizing.
Permara’s design separates identity checks, permissions, payment terms, and execution. The demo shows those decisions without moving real money.
Recipient checks
See who the payment is for and which destination checks are required. A completed identity check does not, on its own, authorize a payment.
See a recipient reviewPayment limits
Review the amount, fees, permitted destinations, and timing before authorization. A proposed alternative must meet the applicable limits.
See a payment stopped at its limitsChanges and approvals
Material changes require the review and approvals defined for the updated terms. Earlier versions remain part of the record.
See a changed request reviewedClear payment states
Authorization, submission, and delivery are shown separately. An uncertain transaction result must be checked before another payment is attempted.
See the payment statesInformation sharing
Review the requested information and recipient before sharing. A credential presentation may include necessary issuer, subject, timing, and cryptographic metadata in addition to the selected claims.
See a disclosure review · Arrives with the disclosure review
Demo status
The screens use sample data and simulated outcomes. Production security, provider arrangements, certifications, and service availability require separate verification before launch.
See the demo bannerWho Permara is
Certifications and status
Stated plainly. Nothing below claims “aligned” or “compliant” without a scope.
Subprocessors
Provider names publish at launch — none are invented here.
Security architecture
Trust endures. Value moves.
When both sides agree, the money moves. Not before.