Process Payments

In This Section

Create a Payment
Print Receipts
Capture Payments
Manage Payment Operations

Now that you’ve authorized a card, you’re ready to create your first Card Present payment.

Create a Payment

To create a payment, use the encoded payment method in the payment_method.encoded_payment_method parameter on the [POST /payments] API request. Be sure to use the value as is, without adding any characters or spaces.

Note

An encoded payment method can only be used once, and every Card Present transaction will need a newly-generated encoded payment method. That said, an encoded payment method will be valid for as long as the authorization. This amount of time will vary depending on the card issuer, but it will generally be 7 days.

So far, you should have the following data points to include in your POST /payments request:

The merchant’s Account ID (this must be the same Account ID which owns the Terminal).
The currency of the transaction (only USD is currently supported).
The encoded payment method (returned by the Card Present SDK).
The authorized amount (returned by the Card Present SDK).

Your request thus far would look like the following:

curl -X POST \
 --url 'https://stage-api.wepay.com/payments' \
  -H 'App-Id: {your-app-id}' \
  -H 'App-Token: {your-app-token}' \
  -H 'Api-Version: 3.0' \
  -H 'Content-Type: application/json' \
  -H ‘Unique-Key: {guid}’ \
  --data-raw '{
"account_id": "{merchant’s-account-id}",
"amount": "{desired-capture-amount}",
"fee_amount": {calculate-processing-and-platform-fees},
"currency”: “USD",
"payment_method": {
	"encoded_payment_method": "{value-from-CP-SDK}""
	}
}’

amount

The amount captured (i.e. the value for the amount parameter in the POST /payments request) should match the amount authorized. In order to capture a different amount, see the Capture Payments section below. Related information on capture scenarios can be found in the Delayed Capture section below as well.

fee_amount

WePay recommends charging, at minimum, WePay’s processing fees in this parameter. Remember that WePay’s processing fees are collected from your platform’s WePay account, which collects funds based on the fee_amount parameter values on Payments facilitated by your platform.

To do this, find your rates in your contract and use those rates to calculate the processing fee per transaction. If your platform’s business model relies on fees per transaction, this would be the place to add those fees in, as well.

Tipping

Tips provided on the receipt will need to be added to the total by the merchant and submitted to your platform via your merchant UI. This means that you should build a check specifically for terminals with tip.mode set to prompt_on_receipt, and use deferred capture to adjust the amount once the merchant has submitted tip amounts at the end of the day.

Tips provided on the terminal are included in the amount parameter of the authorization info object in the auth response from the Card Present SDK.

Denomination

It is important to note that the Card Present SDK represents amounts in dollars while the Payments API represents amounts in cents. For instance, $1.00 in the Card Present SDK should be printed as 1.00, and in the API it should be printed as 100.

Print Receipts

On the Verifone V400m terminal, merchants can print receipts from the device. Identify terminals with printer capabilities by examining the available printer flag in the Card Present SDK.

Verifone V400m terminals display an option for merchants to print a receipt after a successful authorization. If this option is selected, run the print receipt function in the Card Present SDK.

Capture Payments

When calling POST /payments, the auto_capture parameter defaults to true even if it’s not included in the request. This results in an instant capture of the Payment, and requires tips on receipts to be calculated into the total before calling POST /payments.

Note that once a card has been authorized and an encoded payment method has been generated, a POST /payments does not necessarily need to happen right away. As previously mentioned, the expiration of the authorization (and thus, the encoded payment method) will depend on the card issuer, but there is generally a 7 day window. This will give merchants who batch and rely on tipping on receipt time to calculate final totals and submit the information. To further build out for the use case of tipping on receipt, provide a UI for merchants to manually add the tip amount from the receipt to the total amount being submitted.

When auto_capture is set to false, there are a number of possible capture methods, depending on the use case. All use cases below assume that ”auto_capture”: “false” is included in the initial POST /payments API request.

Capture a Payment with no changes

Capture method: manual or delayed
Manual: Send the POST /payments/{id}/capture request with no JSON body.
Delayed: Set the capture_at time in the initial POST /payments API request. The Payment will automatically capture at the designated time.

Capture a Payment with a total less than the authorized amount

Capture method: partial
Partial: Send the POST /payments/{id}/capture request with the new total in the amounts parameter. Be sure to adjust the platform fees so that they do not exceed 20% of the total.

Capture a Payment with a total greater than the authorized amount

Capture method: manual or delayed
Manual: Send the POST /payments/{id}/capture request with the new total in the amounts parameter. Adjust the platform fees as needed, and keep in mind that they cannot exceed 20% of the total.
Delayed: Set the capture_at time in the initial POST /payments request. Before the capture time, send a POST /payments/{id} request to update the amounts on the payment. Adjust fees as needed, and keep in mind that they cannot exceed 20% of the total.

High-Level Capture Flows

All capture flows begin with authorizing a card on the terminal.

Manual Capture		Delayed Capture	Partial Capture
Tip on receipt Call POST /payments with auth amount and `auto_capture: false` Capture with tip amount added in the `amounts` JSON block	Tip on terminal/no tip Call POST /payments with auth amount and `auto_capture: false` Capture with no changes in the JSON body	Call POST /payments with a `capture_at` value and `auto_capture: false` If needed, update Payment prior to capture Payment automatically captures at designated `capture_at` time	Call POST /payments with `auto_capture: false` Capture with `amounts` JSON block being less than initial amount Optional: Create the Payment with `capture_at` and update `amount` prior to capture

Delayed Capture

Use delayed capture to create an API payment which will automatically capture at a designated time up to 7 days from authorization. To create a payment with delayed capture, send a POST /payments API request like this:

curl -X POST \
  --url 'https://stage-api.wepay.com/payments \
  -H 'App-Id: {your-app-id}\
  -H 'App-Token: {your-app-token}\
  -H 'Api-Version: 3.0'\
  -H 'Content-Type: application/json' \
  --data-raw '{
"account_id": "{merchant’s-account-id}",
"amount": "{desired-capture-amount}",
"capture_at": {calculate-UNIX-timestamp-within-7-days-of-current-time}
"fee_amount": {calculate-processing-and-platform-fees},
"currency”: “USD",
"payment_method": {
	"encoded_payment_method": "{value-from-CP-SDK}""
	}
}'

For the sake of example, let’s say the current date and time when you’re sending POST /payments is March 18, 2020 at 3:29:29 PM PST. The farthest out that this payment can be captured would be March 25, 2020 at 3:29:29 PM PST. This means that the maximum UNIX timestamp that you can set as the value for capture_at is 1585175369.

Manual Capture

Manual capture allows a card to be authorized and an API Payment to be created, but the final capture information can be different and the final capture time can be any time within 7 days of authorization.

The final capture amount can be greater than the authorized amount. Capturing an amount less than the authorized amount is considered partial capture. Data related to the payment can be updated, such as Level 2/Level 3 data and custom_data.

Payments using manual capture are typically dependent upon finalized information from the merchant or payer, which is why delayed capture would not be ideal for these payments. Manual capture allows the capture request to be sent as soon as payment details are finalized (i.e. shipping, tip, any changes to amount, or any changes to data), rather than waiting for the capture_at time set in delayed capture.

When creating a payment designated for manual capture, the API request will look like this:

curl -X POST \
  --url 'https://stage-api.wepay.com/payments \
  -H 'App-Id: {your-app-id}\
  -H 'App-Token: {your-app-token}\
  -H 'Api-Version: 3.0'\
  -H 'Content-Type: application/json' \
  --data-raw '{
"account_id": "{merchant’s-account-id}",
"amount": "{desired-capture-amount}",
"auto_capture": false,
"fee_amount": {calculate-processing-and-platform-fees},
"currency”: “USD",
"payment_method": {
	"encoded_payment_method": "{value-from-CP-SDK}""
	}
}'

If rBits or the reference_id need to be updated in addition to amounts, do so using a POST /payments/{id} request:

curl -X POST \
  --url 'https://stage-api.wepay.com/payments/{id}' \
  -H 'App-Id: {your-app-id}' \
  -H 'App-Token: {your-app-token}' \
  -H 'Api-Version: 3.0' \
  -H 'Content-Type: application/json' \
  --data-raw '{
"reference_id": "{new-reference-id}",
"amounts": {
   "amount": {new-capture-amount},
   "currency": "USD",
   "fee_amount": {fee-amount}
  }
}'

The manual capture can be executed using a POST /payments/{id}/capture request with the amounts and/or custom_data JSON blocks, or with no JSON body.

With a JSON body:

curl -X POST \
  --url 'https://stage-api.wepay.com/payments/{id}/capture' \
  -H 'App-Id: {your-app-id}' \
  -H 'App-Token: {your-app-token}' \
  -H 'Api-Version: 3.0' \
  -H 'Content-Type: application/json' \
  --data-raw '{
"amounts": {
  "amount": {new-capture-amount},
  "currency": "USD",
  "fee_amount": {fee-amount}
  }
}'

Without a JSON body:

curl -X POST \
  --url 'https://stage-api.wepay.com/payments/{id}/capture' \
  -H 'App-Id: {your-app-id}' \
  -H 'App-Token: {your-app-token}' \
  -H 'Api-Version: 3.0' \
  -H 'Content-Type: application/json' \

Partial Capture

Partial capture is a version of manual capture which allows a card to be authorized and an API Payment to be created, but the final amount in the manual capture request is less than the authorized amount.

To plan for partial capture scenarios, programmatically create Payments with a POST /payments request where the auto_capture parameter is set to false. The merchant should then have the option to update the amount for capture for 7 days after the API request. To protect against letting authorizations expire before capture, set a capture_at time for the Payment within 7 days. Your POST /payments requests when partial capture is an option should look like this:

curl -X POST \
  --url 'https://stage-api.wepay.com/payments \
  -H 'App-Id: {your-app-id}\
  -H 'App-Token: {your-app-token}\
  -H 'Api-Version: 3.0'\
  -H 'Content-Type: application/json' \
  --data-raw '{
"account_id": "{merchant’s-account-id}",
"amount": "{desired-capture-amount}",
"auto_capture": false,
"capture_at": {calculate-UNIX-timestamp-within-7-days-of-current-time}
"fee_amount": {calculate-processing-and-platform-fees},
"currency”: “USD",
"payment_method": {
	"encoded_payment_method": "{value-from-CP-SDK}""
	}
}'

Note that if the payment is not manually captured, then this payment flow will fallback to the delayed capture flow.

If the merchant opts to partially capture the Payment, then send a POST /payments/{id}/capture request like this:

curl -X POST \
  --url 'https://stage-api.wepay.com/payments/{id}/capture' \
  -H 'App-Id: {your-app-id}' \
  -H 'App-Token: {your-app-token}' \
  -H 'Api-Version: 3.0' \
  -H 'Content-Type: application/json' \
  --data-raw '{
"amounts": {
  "amount": {new-capture-amount},
  "currency": "USD",
  "fee_amount": {fee-amount}
  }
}'

Note that the fee_amount parameter is required in the amounts structure, and it must be no greater than 20% of the new capture amount.

Manage Payment Operations

Partners leveraging WePay’s Clear solution must provide merchants with the tools to manage operations after a payment has been created.

Note

Partners leveraging WePay’s Link solution can direct merchants to their Chase dashboard for these tools.

Issue Refunds

Refund Card Present payments with the Refund API.

For more in-depth guidance, see the Clear developer guide.

Void Payments

Void Card Present payments with the Cancel API.

In order to construct this API request, provide a UI-input for the merchant to submit the text to be used as the value for the cancel_reason parameter.

Your request may look something like this:

curl -X POST \
  --url 'https://stage-api.wepay.com/payments/{ID}/cancel' \
  -H 'Accept: application/json' \
  -H 'App-Id: {your-app-id}'\
  -H 'App-Token: {your-app-token}' \
  -H 'Api-Version: 3.0' \
  -H 'Content-Type: application/json' \
  --data-raw '{
  "cancel_reason": "item(s) delayed - cannot fulfill order"
}'

A successful response will result in a voided payment.

Handle Disputes

Retaining signed receipts for Card Present payments is the best method to challenge any disputes a merchant may receive.

For more in-depth guidance, see the Clear developer guide.

Next Up: Test and Launch

Work through test cases and launch your Card Present integration.

Use WePay’s magic testing values
Certify your integration against WePay’s guides

Test and Launch

Questions? Need help? Visit our support page!