1. HASH
Sipay API Documentation
EN
  • EN
  • TR
  • Overview
    • Getting Started
    • Test Cards
    • IP Restriction
  • Authentication
    • Token Generation
      POST
  • Installments & Commission
    • Installment Details
      POST
    • Commission
      POST
    • Merchant Installments
      POST
  • HASH
    • Hash Creation
    • Hash Validation
  • Non-3DS Payment
    • Non-3DS Payment Flow
    • Non-3DS Card Payment
      POST
    • Non-3DS Recurring Payment
      POST
    • Non-3DS Insurance Payment
      POST
    • Non-3DS Pre-Authorization Payment
      POST
    • Confirm Payment
      POST
  • 3D Secure Payment
    • 3D Secure Payment Flow
    • 3D Secure Card Payment
      POST
    • 3D Secure Recurring Payment
      POST
    • 3D Secure Pre-Authorization Payment
      POST
    • Complete Payment
      POST
    • Confirm Payment
      POST
    • 3D Secure Agriculture Payment
      POST
  • Non-3DS and 3DS Payment with Sipay
    • Purchase Link Example
    • Non-3DS and 3D Secure Payment with Sipay
      POST
  • Check Status
    • Check Status
  • Payment with Saved Card
    • Card Registration
    • 3D Secure Pay by Card Token
    • Non-3DS Pay by Card Token
    • Retrieving Saved Card
    • Edit Saved Card
    • Delete Saved Card
  • Recurring
    • Recurring Query Search
    • Recurring Plan Process
    • Recurring Plan Update
  • Refund
    • Refund
  • Cashout
    • Cashout to Bank
  • Webhook
    • Webhook
  • Status Codes
    • Status Codes
  • Plugin
    • Magento v1
    • Magento v2
    • Opencart
    • Presta
    • Woocommerce
    • Shopify
  1. HASH

Hash Validation

In all responses related to payment transactions, the user may be redirected to the merchant’s success or cancel URL. Since these URLs may be publicly accessible, they may be triggered by unauthorized individuals.
Therefore, it is recommended to include parameters such as status, invoice_id, order_id, and hash_key in the redirect URL. The merchant must validate the hash_key value to verify the validity and source of the incoming request.
For recurring payments, a POST request is sent to the merchant’s webhook URL for each renewal transaction. Since webhook URLs may also be publicly accessible, the source of incoming requests must be verified using hash_key.
The status values are as follows:
3D Secure payments: The status parameter can have a value of 0 or 1.
Recurring Webhook: The $status parameter can have a value of Completed or Fail.
Refund Webhook: The status parameter can have a value of Completed or Fail.
Python
Shell
Go
JavaScript
Java
Swift
C
C#
Ruby
Dart
R
Previous
Hash Creation
Next
Non-3DS Payment
Built with