Stripe Bacs Direct Debit UK – data

When a Stripe Direct Debit (PDD) is submitted by a supporter, you will see several FBR transactions created over time. These are:

1. An initial mandate transaction which is created immediately and is £0 (amount indicated in Campaign Data 20 column)

Note: Until the mandate is confimed by Stripe, Campaign Data 4 will show the amount; after it is confirmed, it will be set to 0.

2. A transaction for each request we make to Stripe, which will initially have a status of “Pending” until Stripe confirm whether it was successful

3. Each of these are followed by a “change” transaction, which details the change of status from “pending” to “success” or “reject” once Stripe confirms

We’ll detail them all here by using some examples.

Example 1 – a series of successful transactions

In the explanation, we’ve abbreviated “Campaign Data” to “CD” for clarity.

• Row 1: Column headings. We’ve selected the most important columns for this explanation. All of them will have a Campaign Type of “FBR”

• Row 2: Mandate. Here the supporter made a direct debit for £1 a month, on the 24th November (first row), with a Recurring Day of 1 (CD 8). Note that the amount (CD4) is 0 for the mandate since it doesn’t represent a real payment. The amount that will be used is under CD20, and the requested start date under CD16.

  The ID of the transaction (CD 1) consists of three IDs – the pm part is an ID related to this mandate and is the same for all related transactions. The cus part is related to the customer and is the same for all related transactions. The mandate part is a unique ID for this row.

• Row 3: The first payment request: Because the recurring day was “1”, Engaging Networks asks Stripe on 1st of the following month (1st December) to make the first payment. The Campaign Status will be “pending” initially while we wait for a response, and then is updated to “success”.

  

  Because of this, the API (which uses staged data) will still always show a “pending” status here, but live exports (from the query builder) will eventually show the updated status

  The ID of the transaction (CD 1) consists of three IDs – the pm and cus parts are the same as before. The pi (payment intent) part is a unique ID for this payment request

• Row 4: Payment request status change: This shows that the status was changed from “pending” to “success”. You can see that the ID (CD1) is the same as the previous transaction since this change relates to that transaction. 

• Row 5: The second payment request: This is made on the 1st of the next month (January). Note the pi ID is different because this is a new payment request

• Row 6: Payment request status change: As before, this shows that the status was changed from pending to success on the 5th January

Example 2 – a series of successful transactions then a cancellation

If a Direct Debit is cancelled via the Recurring Donations gadget, then you’ll get a change transaction relating to that. If it happens after the payment request has been made, then Stripe will still attempt to make that payment but no more requests will be made after a cancellation.

In this example, the supporter chose to give £1 a month on a recurring day of “2” on the 24th November. The direct debit was cancelled on the 5th January. 

You can see that the cancellation (the second last row) has an ID that includes the original mandate ID. Under CD21 it shows the reason for the change if given in the gadget, and the platform user’s email address that made the change under CD22.

What does a payment look like in Stripe?

Metadata

Each payment made in Engaging Networks and passed to Stripe will have Stripe’s metadata stored with it. These are pieces of information about the payment that you can set:

• pagename - the name of the page

• provider - always engagingnetworks

• taxdeductible - for Gift Aid in the UK, this is either Y or N

• appeal code

• other1, other2, other3, and other4