Identify charge transactions

This topic provides information about credit card operations supported by the Charges resource. For complete API details see Payments API Reference.

To immediately capture a credit card charge, use the charges resource with the charges.capture attribute set to true (this is the default setting when using the charges resource). This request, if successful, causes a charge to be incurred by the specified credit card.

Charges authorization is used for a transaction in which the merchant needs authorization of a charge, but does not wish to actually make the charge at this point in time. For example, if a customer orders merchandise to be shipped, you could issue this request at the time of the order to make sure the merchandise will be paid for by the card issuer.

• You perform the authorization using the request to the charges resource with the charges.capture attribute set to false.
• Note the charges.id value returned in the response, as you need it for the subsequent capture operation.
• At the time of actual merchandise shipment, you perform the actual charge using the request to the charges/<id>/capture resource.

Voice authorizations are not supported.

This request is made only after a previous and successful charges authorization request, where the card issuer has authorized a charge to be made against the specified credit card in the future.

• The charges.id from that prior authorization transaction must be used in the subsequent capture transaction.
• At the time of actual merchandise shipment, you perform the actual charge using the request to the charges/<id>/capture endpoint.

This request causes that authorized charge to be incurred against the customer’s credit card.

Notice that you cannot have multiple capture requests against a single request. Each charges request must have one and only one capture.

Send a request to the Charges/<id>/refunds endpoint for both refund and void operations. Intuit Payments figures out whether to request a void or a refund based on factors such as the time of the original transaction. The void or refund is tied to an actual sale or capture transaction via the Charges.id returned in the original create request.

If the original Charge was just an authorization, this request voids the authorization. If you do not void an authorization, the authorization typically expires after 30 days. This potentially leaves a hold on the cardholder’s balance. If the original charge was in captured state (an auth which was captured) or if it was a sale, then there is a time window when a transaction can be voided before the settlement process begins. Once the settlement process begins (typically at 3pm PST), the original charge can only be refunded and not be voided.

For partial refunds, supply a refund amount less than the original amount. If the request is processed as a refund, the amount is checked to make sure it doesn’t exceed the amount of the original transaction.

QuickBooks Payments allows third-party apps to retrieve a receipt for completed transactions which can be provided or made accessible to the payor for each transaction. The receipt is returned in a PDF format.

When a Charge is created via API, the API response contains a field clientTransID, which is the client transaction ID. Use this field in the API call to read the payment receipt.