Stripe n8n integrationAutomate Stripe with n8n.

Reading the account balance is all this operation does. It returns what Stripe currently holds, split between the funds already available and the funds still pending, and there is no field to fill: the node simply queries the account behind the credential you picked.

Charging a payment source already attached to a customer happens here. The operation creates the charge in Stripe and returns the charge object with its status.

• Customer ID: the customer the charge belongs to, often {{ $json.id }} coming from an earlier node.
• Amount: the amount in cents, so 100 stands for one dollar.
• Currency Name or ID: a three letter ISO code such as USD or EUR, chosen from the list or written as an expression.
• Source ID: the payment source of that customer to debit.

One charge, by identifier. The node returns the whole object, so the workflow can branch on the status, the amount or the metadata without a second call.

• Charge ID: the identifier of the charge to retrieve, typically {{ $json.id }} when a charge event started the run.

Pulls a list of charges rather than a single one, with one item per charge in the output.

• Return All: switched on, n8n walks the pages of the Stripe API until every charge of the account comes back.
• Limit: only read when Return All stays off, it caps how many charges a run returns.

Editing a charge after the fact stays narrow on purpose. Four fields sit under Update Fields, Description, Metadata, Receipt Email and Shipping, and nothing else about the payment can move.

• Charge ID: the charge to update.
• Metadata: key and value pairs attached to the charge, added one at a time with Add Metadata Item.

A discount defined in Stripe instead of in your own code. The operation creates the coupon and returns it, ready to be attached to a customer.

• Apply: how long the discount stays in effect, Forever or Once.
• Discount Type: Percent, or Fixed Amount (in Cents).
• Amount Off: the amount in cents to subtract from an invoice total.
• Percent Off: the percentage the coupon takes off.
• Currency Name or ID: the three letter ISO code the amount is expressed in.

Lists the coupons that exist in the account, which is the fastest way to see what is still live before adding another one.

• Return All: on, the node keeps asking for pages until the whole coupon list is out.
• Limit: with Return All off, this caps how many coupons come back.

The customer record anchors almost everything else in Stripe: cards, sources, charges and invoices hang off it. This operation creates it and returns the new identifier.

• Name: the only required field, either the full name or the business name.
• Email: optional in the node, rarely optional in practice, since receipts and invoice emails go there. It sits under Additional Fields, next to Address, Phone, Description, Metadata and Shipping.

Deletes a customer from the Stripe account. One identifier, no options, which makes this operation as easy to wire as it is to fire by accident.

• Customer ID: the customer to delete. Worth guarding with a filter or a manual approval step upstream, because n8n runs the node as soon as an item reaches it.

Fetches one customer and returns the stored record: the name, the email if it was ever set, the address, the metadata.

• Customer ID: the identifier of the customer to retrieve, commonly read from the incoming item with {{ $json.id }}.

Walks the customer list instead of one record, and can narrow it before anything comes back.

• Email: sits under Filters and asks Stripe for the customers matching that address, the closest thing the node offers to a lookup by email.
• Return All: enabled, the node pages through the whole customer list; disabled, Limit decides how many arrive.

Changes what Stripe stores about a customer. Seven fields sit under Update Fields, Address, Description, Email, Metadata, Name, Phone and Shipping, and only the ones you add are touched.

• Customer ID: the customer to update.
• Email: the address Stripe uses for receipts and invoice emails, worth pushing the day it changes in your own database.

Attaches a card to an existing customer. The card details never travel here in the clear: the operation expects a token that already stands for them.

• Customer ID: the customer the card is attached to.
• Card Token: the token representing the sensitive card information, a tok_ string produced by the Create a token operation or by your own checkout.

Reads back one card of one customer. Two identifiers are needed, because a customer can hold several.

• Customer ID: the customer whose card is read.
• Source ID: the source to retrieve, which is the card identifier on that customer.

Detaches a card from a customer. Watch the field name here: this operation asks for a Card ID where the read asks for a Source ID.

• Customer ID: the customer the card belongs to.
• Card ID: the card to remove.

Usage based pricing needs a counter, and this operation feeds it. Each call reports one unit of usage, for one customer, on one meter.

• Event Name: matches the event_name field of the meter configured in Stripe.
• Customer ID: the Stripe customer the usage belongs to.
• Value: an integer, positive or negative.
• Identifier: optional, and worth setting, since uniqueness is enforced inside a rolling 24 hour window, which is what stops a retried run from counting twice.
• Timestamp: the time of the event, within the past 35 calendar days or up to 5 minutes ahead.

Builds a payment source and attaches it to a customer. In the node, Type offers a single value, WeChat, so this is the operation for that payment method rather than a general purpose one.

• Customer ID: the customer the source is attached to.
• Type: WeChat, the only entry in the list.
• Amount and Currency Name or ID: not required by the node, they hold the amount in cents and the ISO code when the source carries one.

Removes a source from a customer, with the same pair of identifiers the read uses. Nothing else is configurable, so the guard has to live upstream in the workflow.

• Customer ID: the customer whose source goes away.
• Source ID: the source to delete.

Returns one source on its own, without naming a customer. Only the source identifier is required, which makes it the quickest way to inspect the object behind a source event.

• Source ID: the identifier of the source to retrieve.

Turns card data into a token, so the card itself is never stored on your side. That token is what Add a customer card expects afterwards.

• Type: the list holds one entry, Card Token.
• Card Number, CVC, Expiration Month and Expiration Year: the card fields, none of them required by the node, filled from whatever collected them. The placeholders show the expected shape, 4242424242424242 for the number and 314 for the security code printed on the back.