Skip to main content

Security Recommendations

Craftgate provides you with an uninterrupted and secure payment experience with its end-to-end solutions. In addition to the solutions offered by Craftgate, we also have suggestions for our Merchant to consider. You can contact support@craftgate.io for your questions and comments.

A. Basic Security Recommendations

API Key / Secret Key Usage​

These 2 values, which are required to use Craftgate APIs, should be stored securely (preferably encrypted) and should not be shared with unauthorized persons. In addition, if you wish, you can renew your existing keys periodically from the Merchant Panel. For more information, you can visit the API Key / Secret Key Management page.

B. Security Recommendations For 3DSecure Payment Flow

Non-3DS & 3D Secure Payment Preference​

Although non-3DS payments are made much faster, they should not be preferred in some cases. It is recommended to pay with 3DS instead of Non-3DS for the following scenarios.

  • 3DS payment is recommended from 'PrePaid' and 'Debit' cards. You can use Craftgate's Retrieve Bin service to access the details of a card.
  • In order to verify the user in the first order of a new member, it is recommended to take payment with 3DS, regardless of the card type to be used.
  • It is recommended to take payment with 3DS, regardless of the card type to be used in the first order of an existing member after a change of address.
  • If a payment error is received with LOST_CARD, STOLEN_CARD, PICKUP_CARD error groups as a result of payment, the user should be followed up and it is recommended to receive new payments with 3DS.
  • It is recommended to receive payments with 3DS in your user's transactions that are much more consistent than normal.

3D Secure Payment Verification Type​

In 3D Secure payments, user verification can be done as full or half verification. Full verification takes place by sending the SMS to the user's phone and entering the verification code correctly. Half-verification takes place in cases where the user is not fully included in the 3D Secure system, and/or the phone is not registered in the bank. Half-verified 3D Secure payments can be completed, but there are risks since the user cannot be fully verified.

As Craftgate, we support both solutions. If you wish, you can choose this option from Merchant Panel -> General Settings.

3D Secure Payment Callback Verification​

In 3D Secure payments, if the user successfully validates himself, the payment flow continues. While transmitting the verification result to the Merchant, the hash value produced by Craftgate is also transmitted along with some parameters. Merchant should compare the incoming parameters with the data on its side, basket control, user session information should be checked. By checking the hash value in the incoming parameters, it should produce the same hash value on its own side and compare the two values. If a hash mismatch occurs the payment should not be continued. For the hash calculation algorithm 3D Secure Payment You can visit the creation page.

You can also verify hashes through the Open Source Libraries that we have presented.

3D Secure Payment Cart Change​

Due to its nature, 3D Secure payments have a flow that takes place in the user's browser and can take an average of 50-60 seconds. Attention should be paid to the changes made by the user to the basket during the period between the initiation, verification and completion of the 3D Secure payment. When the cart changes, the user should be warned and payment should not be continued. 3D Secure payment should be started again with updated basket information.

C. Security Recommendations For Webhook Flow

Webhook Request Verification​

The x-cg-signature-v1 value delivered between the HTTP headers should be examined in order to verify that the requests to your webhook URL are being sent from Craftgate. The information is available on our Webhook page.

C. Security Recommendations For Payment via Common Payment Form

For payments made through the common payment form, as a result, a token information associated with the payment is returned to the merchant's callback address. (See Payment via Common Payment Page) With this token information, retrieve the payment details from the Craftgate common payment page payment retrieve service. (See Retrieving Common Payment Page Payment) Compare the success status of the payment from the payment details returned to you, the values that have special meaning for you, such as the conversation id and external id you transmitted, with the order you checked. In this way, you can be sure that a reliable return is made about the order you checked.

E. Security Recommendations For Error Management

Interpretation of Error Groups​

If the payment transaction results in an error at the bank, Craftgate groups and classifies the error according to the details of the error and returns you with the most accurate error details. You can find the group of the error in the error group field in the payment response, and the cause of the error in the error description. If you wish, you can show this error message directly to your user, or you can show your own error message according to the error group.

If a payment error is received with LOST_CARD, STOLEN_CARD, PICKUP_CARD error groups as a result of payment, the user should be followed due to fraud possibilities. In case of errors such as NOT_SUFFICIENT_FUNDS, RESTRICTED_BY_LAW, the payment can be tried again by informing the user.

You can find the details on our Error Groups page.