# Card payments

Solidgate API for <a href="https://docs.solidgate.com/payments/card-payments/" target="_blank">card payments</a> allows merchants to securely integrate with a payment gateway to process and manage card transactions.

## Charge

 - [POST /charge](https://api-docs.solidgate.com/api/card-payments/make-card-charge.md): Basic operation withdraws funds from the cardholder’s account, with optional 3D Secure verification, and tokenizes the cardholder's data for future payments.

## Google Pay

 - [POST /google-pay](https://api-docs.solidgate.com/api/card-payments/make-google-pay.md): An API request for Google Pay allows a merchant to initiate a Google Pay transaction, by sending a request to the Google Pay API with the required parameters such as amount, currency, and order identifier, which will be processed, and the response will be sent back with the transaction details.

## Apple Pay

 - [POST /apple-pay](https://api-docs.solidgate.com/api/card-payments/make-apple-pay.md): An API request for Apple Pay allows a merchant to initiate an Apple Pay transaction, by sending a request to the Apple Pay API with the required parameters such as amount, currency, and order identifier, which will be processed, and the response will be sent back with the transaction details.

## Incremental auth

 - [POST /increment](https://api-docs.solidgate.com/api/card-payments/increment-card-auth.md): Incremental authorization operation creates additional authorization transactions on top of an estimated authorization to increase the total authorized amount for the order.


  The payment configuration conditions must be met.


                
    Maximum 50 increments allowed per order.


This operation creates a auth transaction with authorization_type incremental within the same order.

## Recurring

 - [POST /recurring](https://api-docs.solidgate.com/api/card-payments/make-card-recurring.md): Method that allows you to initiate tokenized payments. In contrast to charge request, token previously received has to be sent in the request instead of cardholder data.

## Resign

 - [POST /resign](https://api-docs.solidgate.com/api/card-payments/make-card-resign.md): Resign one-click enables token-based transactions (1-click payments) with additional CVV verification, exclusive to PCI-DSS certified merchants.
 Implementing automated retry logic for declined operations is advisable, along with an additional strategy of triggering subsequent attempts at hourly intervals. It is important to ensure that the cumulative retry count remains under 120 attempts.

## Refund

 - [POST /refund](https://api-docs.solidgate.com/api/card-payments/refund-card-order.md): Request for transferring funds back to the cardholder.


  Implementing automated retry logic for declined operations is advisable, along with an additional strategy of triggering subsequent attempts at hourly intervals. It is important to ensure that the cumulative retry count remains under 120 attempts.

## Void

 - [POST /void](https://api-docs.solidgate.com/api/card-payments/void-card-order.md): The void request serves to nullify pre-existing auth transactions by revoking the initial authorization. Be advised that the void method can only be executed for auth transactions. 


  Implementing automated retry logic for declined operations is advisable, along with an additional strategy of triggering subsequent attempts at hourly intervals. It is important to ensure that the cumulative retry count remains under 120 attempts.

## Settle

 - [POST /settle](https://api-docs.solidgate.com/api/card-payments/settle-card-order.md): The settle method facilitates the settlement of previously auth transactions. Be advised that if the subsequent settle amount is less than the initial auth transaction amount, the difference will be refunded to the cardholder's account.


  Implementing automated retry logic for declined operations is advisable, along with an additional strategy of triggering subsequent attempts at hourly intervals. It is important to ensure that the cumulative retry count remains under 120 attempts.

## Check order status

 - [POST /status](https://api-docs.solidgate.com/api/card-payments/get-status-card-order.md): The check order status request helps to retrieve the present status of a given order. 


  If a transaction is undergoing 3D Secure verification, the response indicates an order status of 3ds_verify.

## Get ARN codes

 - [POST /arn-code](https://api-docs.solidgate.com/api/card-payments/get-arn-codes.md): Get ARN codes request obtains ARN codes for specific orders, providing essential information about refunds, currencies, and transaction statuses.

## Updated card order

 - [POST CardsOrderStatus](https://api-docs.solidgate.com/api/card-payments/webhook-card-order-status.md): Webhooks allow merchants to securely receive real-time notifications in card order status changes, for example, from processing to auth_failed, and automatically trigger actions or updates in their own systems based on those events.


  Duplicate webhook events can occur. Implement idempotency on your end to avoid processing the same event twice.

## Created network token

 - [POST NetworkTokenCreated](https://api-docs.solidgate.com/api/card-payments/webhook-network-token-created.md): Webhooks provide merchants with real-time notifications, indicating that the network token associated with a payment card has been issued by Visa or Mastercard. Merchants can then automatically update their systems based on these notifications.


  Duplicate webhook events can occur. Implement idempotency on your end to avoid processing the same event twice.

## Updated network token

 - [POST NetworkTokenUpdated](https://api-docs.solidgate.com/api/card-payments/webhook-network-token-updated.md): Webhooks provide merchants with real-time notifications when the network token associated with a payment card is updated by Visa or Mastercard. These notifications allow merchants to automatically update their systems based on the events.


  Duplicate webhook events can occur. Implement idempotency on your end to avoid processing the same event twice.

## Received dispute

 - [POST Chargeback](https://api-docs.solidgate.com/api/card-payments/webhook-chargeback.md): Webhooks for chargebacks allow merchants to securely receive real-time notifications of chargeback events and automatically trigger actions or updates in their own systems based on those events.


  Duplicate webhook events can occur. Implement idempotency on your end to avoid processing the same event twice.

## Received prevention alert

 - [POST CardPreventAlert](https://api-docs.solidgate.com/api/card-payments/webhook-alert-prevent.md): Webhooks enable to preemptively identify and resolve potential issues, thereby preventing the generation of alert.


  Duplicate webhook events can occur. Implement idempotency on your end to avoid processing the same event twice.

## Received fraud alert

 - [POST FraudAlert](https://api-docs.solidgate.com/api/card-payments/webhook-fraud-alert.md): Webhooks for fraud alerts allow merchants to securely receive real-time notifications of fraud reported by card schemes.


  Duplicate webhook events can occur. Implement idempotency on your end to avoid processing the same event twice.

