open-banking-pay

---
name: open-banking-pay
description: Turns your interest in taking payment by bank transfer instead of card into a plain statement of what an open banking payment actually is under the Payment Services Regulations 2017, what it saves against the card costs set out in the payment-choice skill, and an honest, specific statement of the one protection a customer loses by paying this way, so the decision to offer it is made with that trade-off written down rather than discovered by a customer after a dispute. Use before signing up to an open banking payment provider, and before putting "pay by bank" on a deposit or booking page.
---

# Take payment without the card fee, and what that actually means for the customer who pays that way

You give this whatever quote or proposal you have from an open banking payment provider, and how you intend to use it, such as booking deposits, table reservations or event payments. You get back a plain statement of what the payment actually is in law, what it saves against the card costs the payment-choice skill totals, and a written, honest statement of the protection a paying customer loses compared with a card, so that trade-off is decided in writing rather than discovered by a customer mid-argument. It will not recommend a provider or tell you what proportion of customers will actually use it, because no published adoption figure exists for a single independent UK hospitality business and the willingness to pay this way varies by customer far more than by venue.

## What it does

1. **State plainly what an open banking payment is, because "pay by bank" is not a new payment method, it is a bank transfer with a better interface.** Under the Payment Services Regulations 2017, a payment initiation service is "an online service to initiate a payment order at the request of the payment service user with respect to a payment account held at another payment service provider." The customer's own bank still moves the money, over Faster Payments, in the same way a manual bank transfer would; the open banking provider only initiates that transfer on the customer's instruction, with their consent, inside their own banking app. There is no card, no card scheme, and no card network involved in the transaction at all.

2. **State the saving in the same terms the payment-choice skill uses, so the comparison is like for like.** Because no card scheme is involved, none of the three components that skill totals apply: there is no interchange fee, capped at 0.2 or 0.3 percent under the Interchange Fee Regulation, no card scheme fee, and no acquirer markup on those two. An open banking provider instead charges its own fee, usually a flat amount or a much smaller percentage than a card transaction, because it has none of a card scheme's costs to recover. State the open banking provider's actual fee structure next to the total cost of acceptance already calculated for cards, rather than assuming the saving is the full card rate.

3. **State the one honest downside first, because it is the fact most likely to be missing from a provider's own pitch: an open banking payment carries no chargeback rights.** Chargebacks exist because a card scheme, Visa or Mastercard, operates a dispute mechanism between the cardholder's bank and the merchant's acquirer, built entirely on scheme rules, as the chargebacks skill in this pack sets out. A bank transfer initiated through open banking has no scheme sitting over it and no equivalent mechanism. A customer who pays a deposit this way and is later unhappy with the service has no dispute route through the payment itself, at all, in the way a card-paying customer has under condition 13.3 for services not as described. Their only route is a direct claim against the business under the Consumer Rights Act 2015, the same claim covered in the refund-policy skill, pursued without any payment intermediary to help enforce it.

4. **Separate the fraud protection that does exist from the dispute protection that does not, because the two get confused constantly.** Since 7 October 2024, a mandatory reimbursement requirement has applied to authorised push payment fraud, where a customer is "tricked into sending money to a fraudster," for payments made over Faster Payments or CHAPS between UK bank accounts, with the sending and receiving payment firms splitting the cost of reimbursement. This protects a customer who was deceived into paying a fraudster impersonating the business. It does nothing for a customer who paid the actual business and was simply unhappy with the table, the food or a cancelled booking, because that is not fraud, it is a service dispute, and the reimbursement scheme does not reach it.

5. **Check where an unauthorised transaction sits, because that is a third, different case again.** Where a payment was never authorised by the customer at all, for example their banking app was compromised by someone else, the ordinary refund duty on their own bank under the Payment Services Regulations 2017 applies regardless of payment method, requiring a refund "as soon as practicable, and in any event no later than the end of the business day following the day on which it becomes aware of the unauthorised transaction." This case does not touch the business at all, because the customer's own bank carries the loss, but it is worth knowing the distinction exists so a customer's confused claim of "fraud" can be correctly identified as the service dispute in step 3, the scam in step 4, or the unauthorised transaction in this step, before deciding how to respond to it.

6. **Note variable recurring payments as a developing option, not a settled one, for anything beyond a single payment.** A variable recurring payment allows a customer to authorise a series of future payments up to a limit they set, useful for an instalment plan on a large event booking. This is a newer part of the open banking framework than a single payment initiation, availability and provider support vary, and a business considering it for anything beyond a single deposit should confirm with the specific provider what is actually supported today rather than assume the same maturity as a one-off payment.

7. **Write the customer-facing wording so the saving is offered honestly, without implying a payment method it is not.** Do not describe an open banking payment as "more secure" than a card without qualification; it is regulated and encrypted, but it is not more protective of the customer in a dispute, it is less. Describe it accurately as a direct bank transfer initiated through the provider, and, where the business chooses to offer both, let the customer choose knowing what each option actually gives them.

8. **Hand the cost comparison and the customer-facing wording to Codex once the provider's fee structure is known.** Put the open banking provider's quote, the card total cost of acceptance from the payment-choice skill's output where it exists, and the intended use case in one working folder and run, from that folder:

   ```
   codex exec --sandbox danger-full-access --skip-git-repo-check -C "<working folder>" - < CODEX.md
   ```

   Claude hands over the open banking provider's fee structure and the card comparison figures. Codex returns the cost comparison, the draft customer-facing wording using only the facts supplied, and a gaps file for anything not yet confirmed with the provider. Codex never claims a benefit for open banking payment that was not established in this brief, and never omits the chargeback point from any customer-facing draft.

9. **Decide by use case, not as a single yes or no for the whole business.** A booking deposit that is genuinely non-refundable under the terms set in the refund-policy skill carries little practical downside from the missing dispute route, because there is little for a customer to dispute. A full advance payment for a large event, where the customer's only recourse if something goes wrong is a direct claim against the business, is a different risk, and the two uses do not need the same answer.

## Then it checks

1. The saving stated is calculated against the actual total cost of acceptance from the payment-choice skill, not an assumed card rate.
2. The absence of chargeback rights is stated plainly, in the owner's own decision record and in any customer-facing material that explains the payment option, not left implicit.
3. Fraud protection under the APP reimbursement requirement and dispute protection for a service complaint are stated as two separate, different things, and neither is described using the other's scope.
4. No file describes open banking payment as more secure or more protective for the customer than a card without the qualification that it carries no dispute mechanism.
5. Where variable recurring payments are proposed, the specific provider's current support for it has been confirmed rather than assumed from the general framework.
6. The use case the payment method is being adopted for is named, and the decision is stated for that use case, not as a blanket policy for every payment the business takes.

Any check fails: name it, redo that step once. Failed twice: say what is wrong and stop.

## Rules
- Public information only.
- Never invent a fact, a number or a quote.
- Anything sent in someone's name says whose name it is.
- Never state an adoption rate, a typical proportion of customers who will pay this way, or any other benchmark for a single independent UK hospitality business. No published figure exists.
- Never describe an open banking payment as carrying chargeback rights, dispute rights, or any card-scheme-equivalent protection. It does not, and stating otherwise in customer-facing material misleads the customer about what they are choosing.
- Never present the APP fraud reimbursement requirement as covering a service dispute. It covers being tricked into paying a fraudster, and nothing else.
- Never recommend a specific open banking provider. The skill states what the payment method is and what it costs; choosing a named provider is the owner's decision.
- This output is a working document prepared for the owner to check against the specific provider's actual terms, and for their accountant to check before adopting a new payment method. It applies the Payment Services Regulations 2017 and published PSR policy to facts supplied. It is not financial advice and it is not a determination that any provider's service operates as described.

## Built from
- The Payment Services Regulations 2017, regulation 2, https://www.legislation.gov.uk/uksi/2017/752/regulation/2, read 23 September 2026: the definition of a payment initiation service, quoted in step 1.
- The Payment Services Regulations 2017, regulation 76, https://www.legislation.gov.uk/uksi/2017/752/regulation/76, read 23 September 2026: the unauthorised transaction refund duty, applied to a compromised banking app in step 5.
- Payment Systems Regulator, "APP scams", https://www.psr.org.uk/our-work/app-scams/, read 23 September 2026: the scope of the mandatory reimbursement requirement, limited to being "tricked into sending money to a fraudster," covering Faster Payments and CHAPS between UK bank accounts, with sending and receiving firms splitting reimbursement costs, in step 4.
- Payment Systems Regulator, "PS23/4: APP scams reimbursement policy statement", https://www.psr.org.uk/publications/policy-statements/ps234-app-scams-reimbursement-policy-statement/, read 23 September 2026: the 7 October 2024 commencement date and the confirmation that the framework does not cover disputes over undelivered or misdescribed goods or services, in step 4.
- Regulation (EU) 2015/751 on interchange fees, retained as UK law, https://www.legislation.gov.uk/eur/2015/751, read 23 September 2026: the interchange caps the card cost comparison in step 2 relies on, carried over from the payment-choice skill.

# open-banking-pay

## You are given
The open banking payment provider's quote or proposal, including its fee structure per transaction. The total cost of acceptance for cards, where the payment-choice skill has already produced it, or the owner's current card statement figures where it has not. The intended use case for the open banking payment option, such as booking deposits, full advance payment for events, or general table payment, as decided by the owner. The owner's stated refund-policy position for that use case, where the refund-policy skill has already produced one. Whether the provider supports variable recurring payments and the owner's stated interest in using them. All judgement calls, including whether to adopt open banking payment and for which use case, have already been made by Claude and the owner and are supplied to you as finished facts or an explicit open question.

## Produce
Write into a `./open-banking-pay-output/` folder:

1. `cost-comparison.csv` with columns: `payment_method`, `fee_structure_description`, `fee_percent`, `fee_fixed_gbp`, `applied_to_transaction_value_gbp`, `calculated_cost_gbp`. One row for the open banking provider's fee structure exactly as supplied, and one row per card provider figure supplied from the payment-choice output or the current statement. `calculated_cost_gbp` applies the stated fee structure to `applied_to_transaction_value_gbp`; never estimate a fee structure not supplied.
2. `protection-comparison.md` a table with exactly three rows, `card payment`, `open banking payment initiated in the customer's own consent` and `unauthorised transaction on either method`, and columns for `dispute route for a service complaint`, `fraud or scam protection`, `who bears the loss`. Every cell is drawn only from the facts and citations supplied in the brief; a cell with no supplied fact reads `not established in this brief` rather than being filled from general knowledge.
3. `customer-facing-wording.md` draft wording for a booking or payment page offering the open banking option, stating what it is, that it carries no card-scheme-equivalent dispute route, and any saving passed to the customer if the owner has decided to pass one on. This file is redrafted and reduced to what the brief supports if any claim in it cannot be traced to a fact supplied.
4. `use-case-decision.md` one paragraph per use case supplied, stating whether open banking payment is adopted for it, the reason given, and the refund-policy position that applies to that use case where one was supplied.
5. `gaps.md` a numbered list of: any use case with no stated refund-policy position; whether variable recurring payment support was confirmed with the named provider or only assumed from the general framework; any fee figure not supplied for either payment method; and any claim drafted into `customer-facing-wording.md` and then removed for lack of a supporting fact.

## Rules
- Codex compares and drafts from facts supplied. It never claims open banking payment carries chargeback or dispute rights, never states the APP fraud reimbursement requirement covers a service complaint, and never estimates an adoption rate or a typical proportion of customers choosing either method.
- Never leave `customer-facing-wording.md` implying open banking payment is more secure than a card without also stating it carries no dispute route. Both facts travel together or neither is drafted.
- Never fill `protection-comparison.md` from general knowledge; every cell traces to a fact or citation in the brief.
- Use British English, GBP written as `GBP` or the pound sign, and DD Month YYYY dates. No em dashes in any file you write, and any supplied text containing one is recorded verbatim and flagged in `gaps.md`.
- Every provider name, fee and figure is copied exactly as supplied.
- Every file ends with this line: this is a working document prepared for the owner to check against the specific provider's actual terms, and for their accountant to check before adopting a new payment method. It applies the Payment Services Regulations 2017 and published PSR policy to facts supplied and is not a determination that any provider's service operates as described.

## Return
The absolute path of every file written, the calculated cost for each payment method in `cost-comparison.csv` and the difference between them in pounds, whether `protection-comparison.md` has any cell reading `not established in this brief` and which ones, the decision recorded for each use case in `use-case-decision.md`, and the `gaps.md` item count.