Exchange Request PlatformArabic transaction intake with proof images

The problem & workflow

Select a supported pair → view a fixed estimate → enter synthetic recipient details → attach optional proof → PHP validates → demo accepts or provider confirms → show the server operation number.

Key features

• Supported currency selection and fixed conversion display
• Recipient/account details and optional proof images
• Browser image compression and submission progress
• Server amount/currency/content validation
• Telegram message or photo delivery and operation identifiers
• Demo mode accepts only a demonstration workflow without contacting Telegram

Architecture & decisions

• Server conversion uses the same fixed presentation rate/fees rather than trusting a browser-submitted total. It is not a trading quote.
• finfo and image decoding validate actual upload content; browser MIME is not trusted. The server caps proof images at 5 MB.
• Telegram HTML fields are escaped, TLS verification is enabled and raw request/provider logs are removed.
• A server-issued operation ID replaces the client-generated success number. No public recipient/financial log is published.

Inside the source

• Exchange.html
• post.php
• currency-options.json

A request receipt is different from an executed exchange

I built this interface for exchange-request intake and proof-image submission.

This application collects an exchange request, recipient details and an optional proof image. PHP validates the submission and can send the details and photo to Telegram. The displayed conversion uses configured rates; the receipt identifies intake, not settlement or a live market transaction. Historical tracking and generated marketing activity are identified as presentation features.

That scope shapes the public demo: it accepts synthetic values and never asks an evaluator to submit real financial details. Provider credentials are server-side environment values, and former transaction records and sensitive request logs are excluded from publication.

Treating image and message content as untrusted input

Browser-provided MIME labels are not sufficient evidence that an upload is an image. The server checks content, size and supported request fields, while cURL verifies TLS. User text is escaped before inclusion in Telegram HTML messages so input cannot change the intended formatting.

The local checks cover intake without proof, invalid amounts, unsupported currencies and forged image content. Valid proof delivery and live provider failures remain separate work before operating a real request service. The project demonstrates form UX and server processing; it does not claim automated financial execution.

Project status

Transaction-request interface with PHP and Telegram processing. It does not perform an automated exchange or provide live market data.

Use PHP 8.1+ with fileinfo, image decoding and cURL. Demo mode defaults to enabled; no Telegram key is required. Export .env.example values for live processing, with DEMO_MODE=0 and fresh server-only Telegram credentials. Choose currency labels from currency-options.json. Submit only synthetic recipients and proof images; fixed rates are demonstration estimates.