/* Minification failed. Returning unminified contents.
(1805,5): run-time error CSS1062: Expected semicolon or closing curly-brace, found '-'
(1810,5): run-time error CSS1062: Expected semicolon or closing curly-brace, found '-'
(1811,5): run-time error CSS1062: Expected semicolon or closing curly-brace, found '-'
 */
/*
 * The payment portal is a light-only design: white page, dark navy text, one green primary.
 * There is no dark palette anywhere in this stylesheet, so the page must SAY it is light rather
 * than leave the browser to infer it.
 *
 * Declared because of a real defect, found on a real handset 2026-08-14. Google Pay draws its
 * artwork inside an iframe whose class list ends in `color-scheme-default`, meaning "follow the
 * device". With no declaration here the computed color-scheme was `light dark`, so on a phone set
 * to dark mode Google rendered its DARK button artwork inside the white shell that
 * `buttonColor: 'white'` had correctly produced -- a black Google Pay button on a white page,
 * dominating the screen this phase exists to simplify. Apple Pay was unaffected because its
 * `buttonstyle="white-outline"` attribute is explicit rather than scheme-derived, which is exactly
 * why the two wallets disagreed and made this look like a Converge integration problem.
 *
 * This also stops iOS Safari and Chrome auto-darkening form controls in dark mode -- the ACH
 * holder-name and email inputs already sit at a known-marginal contrast (see the open
 * accessibility todos), and having the browser re-tint them underneath us would make that worse
 * in a way no offline test could see.
 *
 * Keep this at the top of the file: it is a document-level declaration, not a component rule.
 */
:root {
    color-scheme: light;
}

@keyframes spin {
    0% {
        transform: rotate(0deg);
    }

    to {
        transform: rotate(1turn);
    }
}

@keyframes void-animation-out {
    0%, to {
        opacity: 1;
    }
}

* {
  box-sizing: border-box;
}

blockquote, body, button, dd, dl, figure, h1, h2, h3, h4, h5, h6, ol, p, pre, ul {
  margin: 0;
  padding: 0;
}

ol, ul {
  list-style: none;
}

a {
  text-decoration: none;
}

button, select {
  border: none;
  outline: none;
  background: none;
  font-family: inherit;
}

a, button, input, select, textarea {
  -webkit-tap-highlight-color: transparent;
}

:root {
  overflow-x: hidden;
  height: 100%;
}

body {
    background: #fff;
    background-color: #fff /*#f6f9fc*/;
    min-height: 100%;
    display: -ms-flexbox;
    display: flex;
    -ms-flex-direction: column;
    flex-direction: column;
    font-size: 62.5%;
    font-family: Roboto, Open Sans, Segoe UI, sans-serif;
    font-weight: 400;
    font-style: normal;
    -webkit-text-size-adjust: 100%;
    -webkit-font-smoothing: antialiased;
    -moz-osx-font-smoothing: grayscale;
    text-rendering: optimizeLegibility;
    font-feature-settings: "pnum";
    font-variant-numeric: proportional-nums;
    overflow-x: hidden;
}

/*
 * Shared layout
*/

/*
 * `body` is already a full-height column flex container, so `.globalContent`
 * fills the viewport. Making it a column flex container too, and letting
 * `.container` take the free space, pins `.footer` to the bottom of the screen
 * instead of leaving it stranded wherever the content happened to stop.
 * `.cell` (flex: auto, align-items: stretch) then grows with `.container`, so
 * the white card reaches down to the footer as one clean sheet.
 */
.globalContent {
    -ms-flex-positive: 1;
    flex-grow: 1;
    position: relative;
    display: -ms-flexbox;
    display: flex;
    -ms-flex-direction: column;
    flex-direction: column;
    z-index: 1;
}

/*
 * `1 0 auto`, NOT `1 1 auto`. A column flex item that can shrink gets squeezed
 * below its own content height, which would clip the checkout screen once the
 * card fields and wallet buttons are revealed. Grow into free space, never
 * shrink. portal-footer.layout.spec.ts guards this with a long-content case.
 */
.globalContent > .container {
    -ms-flex: 1 0 auto;
    flex: 1 0 auto;
}

.container {
    display: -ms-flexbox;
    display: flex;
    -ms-flex-wrap: wrap;
    flex-wrap: wrap;
    position: relative;
    width: 100%;
    max-width: 750px;
    margin: 0 auto;
    padding: 2px 20px 10px 20px;
    /*height: 95vh;*/ /* to keep footer */
    min-height: 490px;
}

/*
 * `margin-top: auto` (the `auto` in the shorthand's top slot) absorbs any free
 * space left in `.globalContent`, which is the belt to `.container`'s braces:
 * the footer sits on the bottom edge of the viewport on short pages and
 * immediately after the content on long ones. Horizontal `auto` is unchanged.
 */
.footer {
    text-align: center;
    margin: auto auto 0 auto;
    padding: 0 0 10px 0;
    font-weight: 300;
    /*
     * Clearly secondary, not invisible: one step down from the 14px it was, and
     * the paler grey already used by `.cell fieldset legend` and
     * `.card-only .pm-stored-link` rather than a new one.
     */
    font-size: 12px;
    line-height: 18px;
    color: #8898aa;
}

/*
 * Payment Cell
*/

.cell {
    display: -ms-flexbox;
    display: flex;
    -ms-flex-direction: column;
    -ms-flex-align: center;
    flex-direction: column;
    -ms-flex-pack: center;
    justify-content: flex-start;
    position: relative;
    -ms-flex: auto;
    flex: auto;
    min-width: 100%;
    min-height: 630px;
    align-items: center;
    border-radius: 4px;
    box-shadow: 0 7px 14px rgba(50, 50, 93, 0.1), 0 3px 6px rgba(0, 0, 0, 0.08);
    padding: 2px 0px 10px 0px;
    margin-left: -20px;
    margin-right: -20px;
    background-color: #fff;/*#f6f9fc;*/
}

/*
 * Sparse screens sit a third of the way down the card, not pinned to its top
 * (quick task 260810-c4y, "on a page with not much like this page, can we
 * rebalance everything down just a little").
 *
 * `.cell` keeps `justify-content: flex-start`, so after 260810-b8o filled the
 * card down to the footer all of the free space landed BELOW the content. These
 * two zero-basis spacers absorb it at a 1:2 ratio instead. Measured at 430x800
 * on the intro screen, space above the logo / below the last button:
 *
 *     flex-start (before)  2 / 304
 *     1:2 (this rule)     88 / 218
 *     1:1 (fully centred) 131 / 175   <- deliberately NOT this: "just a little"
 *
 * Applied globally rather than behind a breakpoint because it provably does
 * nothing when the card is full: `flex-basis: 0` spacers can only consume FREE
 * space, and a tall page has none. Verified on the expanded checkout at 430x800
 * and in a short 430x500 window - card 1298px, 2px above the logo, footer 10px
 * after the card, page scrolls - identical with and without this rule.
 *
 * `.cell *` zeroes margin/padding but matches elements only, so it leaves these
 * pseudo-elements alone. portal-nudge.layout.spec.ts guards both halves.
 */
.cell::before,
.cell::after {
    content: '';
}

.cell::before {
    -ms-flex: 1 1 0px;
    flex: 1 1 0;
}

.cell::after {
    -ms-flex: 2 1 0px;
    flex: 2 1 0;
}

@media (min-width: 670px) {
  .cell {
    padding: 2px 20px 10px 20px;
  }
}

.cell * {
    margin: 0;
    padding: 0;
    font-family: Inter UI, Open Sans, Segoe UI, sans-serif;
    font-size: 16px;
    font-weight: 500;
}

.cell input, .cell button {
    -webkit-animation: 1ms void-animation-out;
    -webkit-appearance: none;
    -moz-appearance: none;
    appearance: none;
    outline: none;
    border-style: none;
    border-radius: 0;
    color: #fff;
}
    .cell input:-webkit-autofill {
        transition: background-color 100000000s;
        -webkit-animation: 1ms void-animation-out;
    }
    .cell input::-webkit-input-placeholder {
        color: #9bacc8;
    }
    .cell input::-moz-placeholder {
        color: #9bacc8;
    }
    .cell input:-ms-input-placeholder {
        color: #9bacc8;
    }

.cell button {
    display: block;
    width: 100%;
    height: 41px;
    background-color: #24b47e;
    border-radius: 22px;
    color: #fff;
    cursor: pointer;
    font-size:18px;
    font-weight: 600;
    padding: 0 0 2px 0;
}
    .cell button:active {
        background-color: #159570;
    }

    .cell button#btn-pdf {
        background-color: #515e80;
    }

    .cell button#btn-ods {
        background-color: #515e80;
    }

    .cell button#btn-dispute, .cell button#btn-backintro, .cell button#btn-closeconfirm {
        background-color: #9bacc8;
    }

    .cell button#btn-backhome {
        background-color: #204f9b;
    }

    .cell button#btn-cancel {
        background-color: #9bacc8;
    }

    .cell button#btn-backfromreceipt {
        background-color: #9bacc8;
    }

.cell .intro {
    min-width: 250px;
}

.cell form {
    position: relative;
    width: 100%;
    max-width: 496px;
    transition-property: opacity, transform;
    transition-duration: 0.35s;
    transition-timing-function: cubic-bezier(0.165, 0.84, 0.44, 1);
    padding: 0 15px;
}
    /*take all children of the form and select all after them */
    /*.cell form > * + * { 
        margin-top: 28px;
    }
    */
    .cell form input::-webkit-input-placeholder {
        opacity: 1;
    }
    .cell form input::-moz-placeholder {
        opacity: 1;
    }
    .cell form input:-ms-input-placeholder {
        opacity: 1;
    }

    .cell form#form-pay {
        margin-top: 24px;
    }

        .cell form#form-pay.on-plan-details {
            margin-top: 0px;
        }
    

    .cell form.form-direct {
        max-width: 280px;
    }

    .cell form #cell-paymentRequest {
        margin-top: 10px;
    }

    .cell form#form-pay .value-text {
        padding-top: 5px;
    }

    .cell form .receipt-header {
        font-size: 20px;
        font-weight: 500;
        text-align: center;
        color: #32325d;
        margin-bottom: 10px;
    }

.cell #full-block, .cell #due-block {
    cursor: pointer;
}

.cell fieldset {
    border-style: none;
    padding: 5px;
    margin-left: -5px;
    margin-right: -5px;
    background: rgba(18, 91, 152, 0.05);
    border-radius: 8px;
}
    .cell fieldset legend {
        float: left;
        width: 100%;
        text-align: center;
        font-size: 13px;
        color: #8898aa;
        padding: 3px 10px 7px;
    }
        .cell fieldset legend + * {
            clear: both;
        }

.cell .text-block {
    -ms-flex-align: center;
    align-items: center;
    text-align: center;
    padding: 0px;
    margin: 8px 0 0 0;
}

/*
 * The -20px side margins below cancel the 20px horizontal padding .cell only
 * carries at >=670px. Applied unconditionally they made every text block 40px
 * wider than a phone viewport, so the full-width pill buttons inside lost their
 * rounded ends off both screen edges. Keep them paired with the padding they
 * compensate for.
 *
 * A text block nested in .cell form already sits inside the form's 0 15px
 * padding. One that is a direct child of .cell (every .text-block.intro on the
 * portal) has no gutter below 670px, so it supplies its own and lands on the
 * same 30px inset as the checkout buttons.
 */
/*
 * `width: 100%` because this block is a flex item under `.cell`'s
 * `align-items: center`, so its cross size is fit-content. On a sparse intro
 * (short payer name, no account note) the content is narrower than the card and
 * the block lands on the 250px floor from `.cell .intro`. The 30px gutters then
 * take 60 of those 250, leaving 190px buttons - too tight for "View PDF
 * Statement" and "Setup Payment Plan".
 *
 * Filling the card instead gives every intro button the same width and room for
 * its label: 315px at a 375 viewport, 370px at 430. Reset to `auto` at >=670px
 * so the desktop layout is byte-for-byte what it was.
 */
.cell > .text-block {
    padding: 0 30px;
    width: 100%;
}

@media (min-width: 670px) {
    .cell .text-block {
        margin: 8px -20px 0 -20px;
    }

    .cell > .text-block {
        padding: 0px;
        width: auto;
    }
}

.cell .text-block div {
    margin-top: 12px;
}

.cell div.paymentstring-block {
    min-width: 250px;
    margin-top: 25px;
    -ms-flex-align: center;
    align-items: center;
    text-align: center;
    padding-left: 15px;
    padding-right: 15px;
}
    
.cell a.a-backhome {
    font-size: 20px;
    color: #6b7c93;
    text-decoration: underline;
    margin-top: 22px;
}

.cell .text-block button {
    margin-top: 22px;
}

    .cell .text-block button:first-of-type {
        margin-top: 30px;
    }

    .cell .text-block form.form-dispute button {
        margin-top: 22px;
    }

/*
 * Vertical rhythm on the portal intro (quick task 260810-cwq). The groups were
 * pressed too close together on a phone; these roughly double the gaps between
 * them. Measured at 430x800: logo -> first group 20 -> 36 (the intro block's own
 * 8px margin plus the 28 below), between groups 12 -> 24, note -> first button
 * 30 -> 38, button -> button 22 -> 26. The label-to-value gaps stay at 0 - a
 * heading and its amount are a pair, and only the space BETWEEN groups grows.
 *
 * THE PLACEMENT IS LOAD-BEARING. Every rule here ties on specificity with the
 * rule above that it overrides - `.cell > .text-block > div` and
 * `.cell .text-block div` are both (0,2,1), as are the two button rules, and the
 * :first-of-type pair are both (0,3,1). Equal specificity means source order
 * decides, so these MUST stay below their counterparts. Move them up and they
 * will still parse, still be valid, and quietly do nothing.
 *
 * The child combinator is the scope. `.text-block.intro` is a direct child of
 * `.cell`; the checkout screen's `.pay-full` / `.pay-due` / `.pay-custom` blocks
 * sit inside `#form-pay`, so `>` leaves their spacing exactly where 260810-1cm
 * settled it. Loosening either combinator would move the checkout screen too.
 */
.cell > .text-block > div {
    margin-top: 24px;
}

    .cell > .text-block > div:first-child {
        margin-top: 28px;
    }

.cell > .text-block button {
    margin-top: 26px;
}

    .cell > .text-block button:first-of-type {
        margin-top: 38px;
    }

/*
 * The pay-status message block (Phase 28, INS-03). When nothing is payable the Pay button is
 * hidden and this sentence takes its place, so it carries the button's own 38px top gap and
 * leaves the gap below to the surviving buttons' 26px rule.
 *
 * THE SELECTOR IS DELIBERATELY (0,3,0), and the placement below is load-bearing for the same
 * reason as the block above. Two rules can match this element: `.cell .text-block div` and
 * `.cell > .text-block > div`, both (0,2,1). A bare `.pay-status-note` is (0,1,0) and loses to
 * both, which would quietly give the block 24px instead of 38px -- valid CSS, no error, wrong
 * spacing.
 *
 * One rule in this region does outrank it: `.cell > .text-block > div:first-child` above is
 * (0,3,1) and sets margin-top: 28px. That is NOT a specificity fight this rule wins -- it is
 * unreachable for a structural reason. The message block is never the first child of
 * `.text-block.intro`, because Family Account (Card.cshtml:20-23) and #full-block always precede
 * it on both in-scope views.
 *
 * The inner `p` needs its own selector because `.cell *` (line 210) sets font-size and
 * font-weight directly on every descendant at (0,1,0), which beats inheritance from this block.
 * Stating them explicitly means a future `.cell *` edit cannot silently restyle the message.
 *
 * No text-align: `.cell .text-block` already centres. No white-space, no fixed height, no
 * truncation -- the sentence must be free to wrap. This does not reuse .div-goodnews /
 * .div-badnews: those fail contrast at 3.6:1, and on this screen that banner means a payment
 * succeeded.
 */
.cell > .text-block > .pay-status-note {
    margin-top: 38px;
    margin-bottom: 0;
    padding: 12px 16px;
    background: rgba(18, 91, 152, 0.05);
    border-radius: 8px;
    color: #32325d;
}

    .cell > .text-block > .pay-status-note p {
        color: #32325d;
        font-size: 16px;
        line-height: 22px;
        font-weight: 500;
    }

    .cell .text-block a.a-payother {
        font-size: 20px;
        color: black;
        display: none;
        text-decoration: underline;
        margin-top: 22px;
    }

    .cell .text-block a.a-cancel {
        font-size: 18px;
        color: #6b7c93;
        display: block;
        text-decoration: underline;
        margin-top: 16px;
    }

    .cell .text-block .custom-amount-block {        
        margin: 0px 20px;
        margin-top: 12px;
    }
        .cell .text-block .custom-amount-block button {
            margin-top: 36px;
            margin-bottom: 30px;
        }

        .cell .text-block .custom-amount-block .custom-amount-warning {
            color: #e25950;
            font-size: 13px;
            margin-top: 4px;            
        }

.cell .div-direct {
    padding: 0px;
    margin: 18px 0 0 0;
}

/* Same breakpoint pairing as .cell .text-block above. .div-direct is always
   inside .cell form, so the form's 0 15px padding is its gutter below 670px. */
@media (min-width: 670px) {
    .cell .div-direct {
        margin: 18px -20px 0 -20px;
    }
}

    .cell .div-direct div {
        margin-top: 12px;
    }

    .cell .div-direct button {
        margin-top: 22px;
    }

.cell .sub-value-text
{
    font-size: 12px;
    color: gray;
    font-weight: 300;
    padding-top: 5px;
}

/*
 * CSS-02, RECORDED RATHER THAN FIXED, and the reason is in the last paragraph.
 *
 * In POSITION A - today's shipped placement, and the only one FeeDisclosureWithMethod
 * can produce by construction - this block sits above the four amount blocks and the
 * 40px is correct and untouched.
 *
 * In POSITION B it renders between the last amount block and section 1's first
 * container (AccountOrCard.cshtml:320-323), where this 40px collapses against that
 * container's 10px to max(40, 10) = 40px - reinstating exactly the gap the rhythm
 * comment at :1367-1398 says the operator flagged, and which :1400-1425 adds a 30px
 * top margin to `.cell .button-ach-container` specifically to close. Position B needs
 * 30px here, not 40px.
 *
 * NOT FIXED because there is no safe way to express "40 in A, 30 in B" today. The
 * partial is byte-identical at both sites by design (one element, never two - see the
 * Position A comment in the view), the two sites differ only by which element FOLLOWS
 * the block, and CSS has no previous-sibling combinator. `:has()` would do it, but it
 * is unsupported on exactly the iOS population this phase's HIGH-1 fix exists for, so
 * the rule would silently drop there and leave the hole anyway - a fix that works on
 * the reviewer's browser and not on the patient's.
 *
 * PAY-05 IS AN OPEN OPERATOR CHOICE. If Position B is selected, change this to 30px
 * at the same time: A and B never ship together, so the value can simply move rather
 * than be conditional. Recorded here, at the rule, rather than in a review document
 * nobody reads at switch-flipping time.
 */
.cell .conv-fee-container {
    margin-bottom: 40px;
}

/* PAY-05. The fee disclosure is ONE QUIET PARAGRAPH with no heading over it, which is what a
   patient saw before this phase (see docs/payment-portal-screenshots/2026-08-12-Snellville-jv-
   test-account-1.PNG). An interim revision added an `.cf-heading` label at 14px/600/#32325d over
   14px/500 body text; the operator asked for that reversed - the fee must read as muted, not as
   a callout - so both the heading element and its rule are gone. Do not reintroduce a label
   here: with no heading there is no element that can outlive its value when init.js hides the
   whole container, and no fourth hide site to forget.

   Size and weight are back to the original 12px / 300. The COLOUR is not: the original #808080
   measures 3.949:1 on this card's #fff (.cell, line 163) and FAILS the 4.5:1 WCAG AA bar for
   text under 24px, on a consumer fee disclosure. #757575 is the same neutral grey darkened to
   4.608:1 - a hair off #808080 to the eye, with margin over the bar rather than the 4.542:1
   #767676 would have scraped by on. Muted comes from size, weight and position; it never comes
   from failing contrast. `the fee disclosure is muted AND clears the contrast bar` measures both
   off the rendered element, so a future re-lightening fails by name.

   Both properties are explicit because `.cell *` (line 210) sets font-size and font-weight on
   every descendant at (0,1,0) and beats inheritance. */
.cell .cf-value-text {
    font-size: 12px;
    color: #757575;
    font-weight: 300;
}

.cell .header-text {
    font-weight: 500;
    font-size: 16px;
    line-height: 22px;
    color: #6b7c93;
}

.cell .underheader-text {    
    display: block;
    font-weight: normal;
    font-size: 12px;
    color: #6b7c93;
}

.cell .value-text {
    font-weight: 600;
    font-size: 22px;
    line-height: 28px;
}

.cell .value-text.formula {    
    font-size: 30px;
    line-height: 46px;
}

.cell .paymentstring-text {
    margin-top: 2px;
    display: block;
    font-weight: normal;
    font-size: 14px;
    color: #6b7c93;
}

    .cell .paymentstring-text a {
        color: #6b7c93;
        cursor: pointer;
        text-decoration: underline;
    }

.cell .pay-full, .cell .pay-due, .cell .pay-custom, .pay-request {
    display: none;
    margin-bottom: 20px;
}

.cell .pm-card-field {
    display: none;
    margin-top: 10px;
}

/*
 * THE INSTRUMENT-BLOCK PANEL - 29-UI-SPEC.md `### Instrument block`:
 * "Panel: rgba(18,91,152,0.05) background, 8px radius, 12px 16px padding."
 *
 * ONE declaration block behind BOTH selectors, for the same reason the change
 * control below is written that way: PAY-02 asks that a saved card and a saved
 * bank read as the SAME KIND OF THING. 29-01 made the three `Change` controls
 * identical; the blocks they sit in were left bare (`display:none` and a margin,
 * nothing else) so the two instruments still read as different objects - the
 * card as a floating underlined line, the bank as centred text on nothing. Split
 * this into two rules with two copies of the values and they will drift.
 *
 * The tint is REUSED, not invented: it is byte-identical to `.cell fieldset`
 * (base.css:348) and `.cell > .text-block > .pay-status-note` (base.css:510),
 * which is why 29-UI-SPEC's Color table calls it "already the tint used by" them.
 *
 * Cascade arithmetic, because two rules above set the same three properties:
 *
 *   .cell *              (0,1,0)  base.css:210   margin:0; padding:0
 *   .cell .text-block    (0,2,0)  base.css:363   padding:0px; margin:8px 0 0 0
 *   THIS RULE            (0,2,0)  ties .text-block - and wins on SOURCE ORDER
 *                                 only because it sits BELOW it. Moving this
 *                                 block above line 363 would leave it valid,
 *                                 parsed, and silently doing nothing.
 *
 * background/border-radius have no competitor, but padding does, so the whole
 * rule has to stay here.
 *
 * `.cell .text-block div` (base.css:411) puts margin-top:12px on the first child
 * of each of these blocks. With padding:0 that margin collapsed THROUGH the
 * block's top edge; adding padding stops the collapse, so the same 12px would be
 * added to the new 12px of top padding and the panel would sit visibly
 * lopsided - 24px above the name, 12px below the button. The :first-child reset
 * below is that fix, not tidying. It is (0,3,0) and beats (0,2,1).
 */
.cell .pm-stored-card, .cell .pm-stored-account {
    display: none;
    position: relative;
    margin-bottom: 30px;
    padding: 12px 16px;
    background: rgba(18, 91, 152, 0.05);
    border-radius: 8px;
}
    .cell .pm-stored-card > *:first-child, .cell .pm-stored-account > *:first-child {
        margin-top: 0;
    }
    .cell .pm-stored-card.remove-space, .cell .pm-stored-account.remove-space {
        margin-bottom: 2px;
    }

/*
 * THE ONE-ROW INSTRUMENT LAYOUT - the operator's request, verbatim: "the credit
 * card block above is taking up too much vertical space ... some small edit icon
 * ... to the right to indicate clicking anywhere on the row to edit that credit
 * card. also expires on the same line to save vertical space."
 *
 * Three stacked rows became one: the block used to be name / expiry / a 44px
 * `Change` pill on its own line with `margin: 12px auto 0`. Now the identity and
 * the control are flex siblings, so the panel's height is just the control's 44px
 * plus its 12px+12px padding.
 *
 * WHY A WRAPPER, and not `display:flex` on the panel itself. init.js reveals every
 * one of these blocks with an inline `style.display = 'block'` (init.js pmStoredCard,
 * pmStoredAccountSach, pmStoredAccountPlaid) and hides them the same way. An inline
 * style beats any stylesheet rule, so a `display:flex` here would be silently
 * overwritten with `block` the moment a saved instrument was revealed - valid,
 * parsed, and doing nothing. The wrapper's own display is never written by JS.
 *
 * `min-width: 0` on the identity is not tidying: a flex item's default
 * `min-width:auto` refuses to shrink below its content, so a long masked account
 * name would push the pencil off the panel instead of wrapping. It is the flexbox
 * half of the same guarantee `overflow-wrap: anywhere` gives below.
 *
 * `.cell .text-block div` (base.css:411) puts `margin-top: 12px` on EVERY div
 * inside these blocks. Before this change the identity was the panel's first child
 * and the `:first-child` reset above zeroed it; now it is a grandchild, so the reset
 * no longer reaches it and the row would sit 12px low inside its own padding. That
 * is what the reset below fixes. (0,3,0) beats `.cell .text-block div` at (0,2,1)
 * on class count.
 */
.cell .pm-stored-card .pm-instrument-row, .cell .pm-stored-account .pm-instrument-row {
    display: flex;
    align-items: center;
    /*
     * 4px, not the 8px this shipped with. Every pixel between the identity and
     * the pencil is a pixel the identity cannot use, and the arithmetic in the
     * block below is decided in single digits. The overlay makes the whole panel
     * one hit area, so this gap is a visual separation only - it is not, and
     * never was, dead space between two different tap targets.
     */
    gap: 4px;
}
    .cell .text-block .pm-instrument-row > * {
        margin-top: 0;
    }
    /*
     * THE OPERATOR'S REQUEST, verbatim: "About the credit card row. Should be
     * centered vertically".
     *
     * It was off by exactly 6px, and only on the CARD row. `.cell .text-block div`
     * (base.css:411) puts `margin-top: 12px` on every div inside these panels. The
     * reset above catches the row's DIRECT children, which is all the two bank rows
     * have - their `.pm-account-name` measured dead centre. The card's identity is a
     * generation deeper: `.pm-logo-1` and `.pm-text-1` are children of
     * `.pm-logo-table`, so the reset never reached them and each carried the 12px.
     *
     * `align-items: center` then did exactly what it was asked to: it centred a
     * 34px box (22px of content plus 12px of margin) whose content sat at the
     * BOTTOM of it. Measured at 390px, the brand mark, the card name and the expiry
     * all sat 6px below the centre line the pencil sat on. Nothing about it read as
     * a broken layout, which is why it survived - a whole row 6px low looks like a
     * choice.
     *
     * (0,4,0), so it beats `.cell .text-block div` at (0,2,1) on class count rather
     * than on source order. Scoped to the identity's own table so it cannot reach
     * anything outside a one-row panel.
     */
    .cell .text-block .pm-instrument-row .pm-logo-table > * {
        margin-top: 0;
    }
    .cell .text-block .pm-instrument-row > .pm-logo-table,
    .cell .text-block .pm-instrument-row > .pm-account-name {
        flex: 1 1 auto;
        min-width: 0;
    }

/*
 * THE ONE-LINE IDENTITY, AND WHY THE TABLE HAD TO GO.
 *
 * MEASURED, at 390px, against the strings PRODUCTION actually emits - not the
 * fixture strings this first shipped against. The production shapes come from
 * three C# sources, and the spec derives them from those files rather than
 * retyping them (see `PRODUCTION` in pay-action-area.layout.spec.ts):
 *
 *   card name    PaymentManagement.cs:531  "{Brand}&nbsp;••••&nbsp;{Last4}"
 *   card expiry  PaymentManagement.cs:545  "exp&nbsp;{MM}/{yyyy}"
 *   Stripe bank  CheckoutController.cs:492 "{BankName}••••{Last4}"
 *   Plaid bank   Plaid/AccountManagement.cs:102 "{AccountName} ••• {Mask}"
 *
 * Note the mask is BULLET U+2022 between two NO-BREAK SPACES, and the expiry is
 * a four-digit year behind a no-break space. The fixtures this shipped against
 * used MIDDLE DOT U+00B7 and `Exp 12/26` - both narrower than the real thing, so
 * every measurement taken with them was optimistic. Re-measured with the real
 * shapes and the brand logo present, the card row WRAPPED for every one of the
 * brands ConvertCardBrand can emit. It did not show up as a height regression
 * because the 44px control sets the row's height: a two-line identity still
 * reports a 68px panel. The operator's own comparison image is the proof -
 * "Testcard ····0000 · Expires" over "01/2030".
 *
 * THE BUDGET, at 390px. The panel is 330px wide and its 16px side padding leaves
 * a 298px row. The change control is 46px and the gap 4px, so the identity gets
 * 248px, of which the expiry and its separator take a fixed 89px. The widest
 * identity production can build is `MasterCard •••• 0000` at 162.5px, and that
 * is before the brand logo. There is no arrangement of a 51px logo, a 44px touch
 * target and 16px/600 + 14px type that fits every brand on one 298px line. So
 * the layout has to decide what gives, and it decides in this order:
 *
 *   1. the brand logo shrinks, to a 32px legibility floor
 *   2. then the NAME truncates with an ellipsis
 *   3. nothing ever wraps, and nothing ever moves the panel off 68px
 *
 * Measured outcome: Visa, Amex, JCB and PayPal render whole; MasterCard,
 * Discover, Diners Club and Union Pay lose the tail of the brand word.
 *
 * The name is the element that yields because the brand logo sits immediately to
 * its left saying the same word: on `MasterCard •••• 0000` beside a MasterCard
 * mark, the first ten characters are the only redundant thing on the row. The
 * expiry never truncates - a half-rendered date ("exp 12/20") is a worse defect
 * than a clipped brand, and it is fixed-width, so it can be reserved.
 *
 * WHY NOT THE TABLE. `.pm-logo-table` is `display: table` with auto layout, and
 * auto table layout distributes to MIN-CONTENT: it hands the text cell the width
 * its longest unbreakable word needs and no more, then wraps the rest. A table
 * cell cannot be told "shrink this one and clip it". Flex can, in one line each,
 * and `flex-shrink` is what implements the priority order above. The
 * `.pm-logo-table` ELEMENT stays - portal-rhythm.layout.spec.ts carries a named
 * canary asserting `.pm-stored-card` still wraps it - only its `display` changes,
 * and only inside `.pm-instrument-row`. The bare `.pm-logo-table` / `.pm-text-1`
 * / `.pm-logo-*` rules further down this file are shared with
 * Views/Charge/LegacyForms/*, which this phase does not own and does not touch.
 */
    .cell .pm-instrument-row .pm-logo-table {
        display: flex;
        align-items: center;
        min-width: 0;
    }
    /*
     * The brand mark gets a FIXED 32px on this row, and does not negotiate.
     *
     * Two designs were measured before this one, and both failed in ways worth
     * recording so neither gets re-proposed:
     *
     *   `flex-shrink: 1` on both items. Flex splits a shortfall in proportion to
     *   shrink-factor x base-size, and the name is three times the logo's width,
     *   so the NAME absorbed three quarters of every missing pixel. It started
     *   dropping the patient's last four digits while the brand mark still sat
     *   at its full 51px - the worst possible split of the two.
     *
     *   `flex-shrink: 200` on the logo, `min-width: 32px`. This got the priority
     *   right but left the name starved by a CONSTANT 0.3px: flex resolves the
     *   deficit to the fraction, the logo reclaims every spare fraction, and the
     *   name box lands just under its own text. That is not a rounding curiosity
     *   - `text-overflow: ellipsis` has a cliff, because the ellipsis glyph
     *   itself needs about 10px, so a 0.3px overflow costs TWO CHARACTERS. Amex
     *   rendered `Amex •••• 00…` while missing by a third of a pixel, and it
     *   moved with the row gap, so the set of brands that kept their digits
     *   depended on font rounding.
     *
     * A fixed width removes the negotiation and therefore the cliff: the identity
     * gets a constant 118.9px at 390px, whatever the brand. 32px of a 51x32
     * wordmark is still the fastest recognition cue on the row - what the
     * baseline README pins as a must-not-regress is the mark's presence - and a
     * mark that no longer changes size from brand to brand reads as designed
     * rather than as accidental.
     *
     * `height: auto` keeps the aspect ratio of the real asset: every PNG in
     * Content/images/ms/ is 51x32, so 32 wide draws 20 tall.
     */
    .cell .pm-instrument-row .pm-logo-1 {
        display: block;
        flex: 0 0 auto;
    }
        .cell .pm-instrument-row .pm-logo-1 img {
            display: block;
            width: 32px;
            height: auto;
            margin: 0 8px 0 0;
        }
    /*
     * `.pm-logo-2` is `visibility: hidden` (below) - it has ALWAYS been invisible.
     * What it was not is free: a hidden box still takes part in layout, so on the
     * card row it was consuming up to 67px of the identity's width to draw
     * nothing. That was the single largest cause of the wrap. `display: none`
     * removes it from layout without touching the shared rule that LegacyForms
     * relies on for its own centring.
     */
    .cell .pm-instrument-row .pm-logo-2 {
        display: none;
    }
    .cell .pm-instrument-row .pm-text-1 {
        display: flex;
        align-items: center;
        justify-content: center;
        flex: 0 1 auto;
        min-width: 0;
        /*
         * `width: auto` is load-bearing, not tidying. `.pm-text-1` ships as
         * `width: 1%` further down this file - a table-layout idiom meaning "take
         * min-content and give every spare pixel to the two logo cells". Outside
         * a table that literally computes to one percent of the row, which
         * collapsed the whole identity to a 2px sliver the first time this rule
         * was written without it. It is scoped to `.pm-instrument-row` so the 1%
         * is untouched anywhere else the card logo table is used
         * (Views/Charge/LegacyForms/*, which this phase does not own).
         */
        width: auto;
    }

/*
 * The change control that sits with each saved instrument. ONE declaration block
 * behind TWO selectors, deliberately - do not split it into two rules with two
 * copies of the values, because the whole point is that the three controls
 * cannot drift apart.
 *
 * Why two selectors, as cascade arithmetic:
 *
 *   .cell button                                       (0,1,1)  base.css:242
 *       width, height, background-color, border-radius, color, font-size,
 *       font-weight, padding
 *   .cell input, .cell button                          (0,1,1)  base.css:218
 *       each selector in that list is evaluated on its own; the button half
 *       gives color and border-style
 *   .cell .button-container button                     (0,2,1)  base.css:736
 *       margin
 *   .cell .button-container .ach-new-account-submit-link   (0,3,0)  base.css:761
 *       background, border, padding, margin, font-weight, font-size,
 *       line-height, color, text-decoration, cursor
 *
 * The card control lives in .text-block.pm-stored-card and only has to beat
 * (0,1,1), which .cell button.pm-change-method at (0,2,1) does. The Plaid and
 * Stripe controls live inside .button-container, where a bare (0,2,1) LOSES
 * outright to the (0,3,0) link rule and merely TIES the (0,2,1) margin rule -
 * so the winner would fall out of source order rather than intent, and the
 * Plaid control would ship as a 14px blue underlined link while the other two
 * are 44px pills. .cell .button-container button.pm-change-method is (0,3,1)
 * and wins both. The two !importants that rule carried are dropped at source,
 * because !important outranks specificity entirely.
 *
 * text-decoration, line-height and border are not decoration here: they are
 * exactly the properties .ach-new-account-submit-link sets that would otherwise
 * survive on the Plaid control and make it read as a link. font-size and
 * font-weight are restated rather than inherited because `.cell *` (0,1,0) sets
 * both on every descendant. width:fit-content with margin auto is what stops a
 * full-width control reading as a payment action.
 *
 * Do NOT raise .cell button's own 41px height to reach the 44px touch floor:
 * that moves every button on the screen and breaks two DIFFERENT tests in
 * tests/e2e/specs/portal-rhythm.layout.spec.ts - `the sparse intro still does
 * not scroll` (the real height guard, via its freeBelow slack assertions) and
 * `intro buttons fill the card and match each other` (width only). Both titles
 * carry an `at {w}x{h} ({label})` viewport suffix, so an exact-title --grep
 * matches nothing.
 */
.cell button.pm-change-method, .cell .button-container button.pm-change-method, .cell .directdebit-new-account-button button.pm-use-saved-account {
    display: block;
    width: fit-content;
    height: 44px;
    padding: 0 16px;
    margin: 12px auto 0;
    background-color: #ffffff;
    border: 1px solid #6b7c93;
    border-radius: 22px;
    color: #32325d;
    font-size: 16px;
    font-weight: 600;
    line-height: normal;
    text-decoration: none;
    cursor: pointer;
}

/*
 * The same control, once it sits IN a one-row instrument panel. All three saved
 * instruments get this and none of them may diverge from it - PAY-02 is that a
 * saved card and a saved bank read as the same kind of control, and there are
 * named tests asserting tag, class, computed box and computed style pairwise.
 *
 * `margin: 0` undoes the `12px auto 0` above, which is what put the pill on its
 * OWN LINE - the third of the three stacked rows the operator asked us to lose.
 * `.pm-use-saved-account` shares the rule above and is NOT in a panel, so it keeps
 * its own line; that is why this is a separate rule rather than an edit to that one.
 *
 * (0,4,1). It has to beat `.cell .button-container button.pm-change-method` at
 * (0,3,1), which the two bank controls both match - a tie would fall out of source
 * order rather than intent.
 *
 * display:flex, not the inherited block: the button's only child is now an inline
 * SVG, and an inline box in a 44px block sits on a text baseline rather than in the
 * middle. min-width holds the 44px touch floor on BOTH axes - the icon is small, its
 * hit area is not.
 *
 * ⚠ THE BUTTON IS NOW AN INVISIBLE 44x44 HIT BOX, and the ring the patient sees is
 * drawn on the SVG instead (`.pm-change-method .pm-pencil-icon` below). The
 * operator asked for the control to be "deemphasized and smaller", and those two
 * words pull against the 44px touch floor, which is not negotiable on a payment
 * screen held in one hand. Splitting the drawn shape off the tappable box is what
 * lets both be true: 32px of visible circle inside 44px of target.
 *
 * WHY NOT `::before` FOR THE CIRCLE, which is the obvious way to draw a smaller
 * shape inside a bigger box. An absolutely positioned pseudo-element resolves
 * against its nearest POSITIONED ancestor, so drawing it that way means giving
 * this button `position: relative` - and `.pm-change-method::after` below is the
 * overlay that makes the WHOLE ROW this button's hit area, pinned to the panel
 * precisely because the button is not positioned. Positioning the button would
 * silently collapse that overlay from the panel to the button and take the
 * row-wide tap target with it. The icon is a real child and needs no positioning,
 * so the ring goes there.
 *
 * `padding: 0` and `background-color`/`border-color` transparent undo the shared
 * pill above. The box is then 34px of content against a 44px `min-width`, so it
 * measures exactly 44x44 - 2px narrower than the 46px pill it replaces, which the
 * identity gets back.
 *
 * `color` is the screen's existing secondary grey and is inherited by the ring and
 * the pencil alike through currentColor. It is a deliberate step down from the
 * #32325d this shipped with: 11.1:1 against the panel tint, which made the control
 * the second-darkest thing on the row after the card's own name. At
 * rgb(105, 115, 134) it measures 4.43:1 on the panel - quieter, and still well
 * clear of the 3:1 bar a UI boundary has to meet. Anything lighter starts trading
 * against that bar, and the operator asked for de-emphasised, not invisible.
 */
.cell .pm-stored-card .pm-instrument-row button.pm-change-method,
.cell .pm-stored-account .pm-instrument-row button.pm-change-method {
    display: flex;
    align-items: center;
    justify-content: center;
    flex: 0 0 auto;
    margin: 0;
    min-width: 44px;
    padding: 0;
    background-color: transparent;
    border-color: transparent;
    color: rgb(105, 115, 134);
}

/*
 * "clicking anywhere on the row to edit that credit card" - the operator's words,
 * implemented as ONE REAL CONTROL rather than a click handler on a div.
 *
 * This overlay is why the row is a real button: it is a pseudo-element of the
 * <button>, so a tap anywhere in it is a tap on the button. The row therefore
 * keeps a single accessible name, a single focus stop and keyboard activation for
 * free. A div with a click handler would have had none of the three.
 *
 * `top/right/bottom/left` rather than the `inset` shorthand, deliberately: this is
 * the live payment screen and the shorthand is a 2021 baseline. The longhands are
 * the same declaration everywhere.
 *
 * An absolutely positioned box resolves against the PADDING box of its nearest
 * positioned ancestor, which is why `.pm-stored-card` / `.pm-stored-account` gained
 * `position: relative` above - the overlay covers the panel's 12px/16px padding too,
 * so the row's whole visible area is live, not just its text.
 *
 * The overlay paints above `.pm-text-1`, whose own click binding stays wired in
 * init.js. Both do the identical thing (hide the stored card, show the card fields),
 * so which one receives the tap does not change what the patient gets.
 *
 * Scoped to the panels. `.pm-use-saved-account` matches the shared rule above but
 * is NOT in a panel and must never get an overlay: there is no positioned ancestor
 * around it, so `top:0` would resolve against the initial containing block and it
 * would cover the viewport.
 */
.cell .pm-stored-card .pm-change-method::after,
.cell .pm-stored-account .pm-change-method::after {
    content: "";
    position: absolute;
    top: 0;
    right: 0;
    bottom: 0;
    left: 0;
}

/*
 * The pencil. Inline SVG because this screen has no icon font, no CDN and no build
 * step, and because the offline layout specs slice this markup off disk - anything
 * fetched at runtime would be invisible to them and to a patient on a bad line.
 * It inherits `currentColor` from the button, so it can never drift from the
 * control's own text colour.
 */
.cell .pm-change-method .pm-pencil-icon {
    display: block;
    /*
     * THE DRAWN CONTROL - a 32px circle, inside the 44px hit box the button
     * still measures. "the edit button could be deemphasized and smaller",
     * the operator's words, and this is the "smaller" half: 32px drawn where
     * 46x44 was drawn before.
     *
     * The ring lives HERE rather than on the button for the reason written out
     * at the button's own rule above - drawing it as a positioned
     * pseudo-element would have required positioning the button, which would
     * have collapsed the row-wide tap overlay onto the button itself.
     *
     * `box-sizing: border-box` is the file's global (base.css:16-18) and is
     * restated because the arithmetic depends on it: 32 - 7 - 7 - 1 - 1 leaves
     * a 16px pencil, down from 20px. The touch target does not move with it;
     * it is the button's 44px, and the whole row's overlay beyond that.
     *
     * `currentColor` on the border, so the ring can never drift from the
     * pencil it encircles or from the button's own colour - one declaration
     * de-emphasises all three. The white fill is what keeps it reading as a
     * control against the panel's blue-grey tint rather than as an outline
     * drawn on the panel.
     *
     * `stroke-width` overrides the SVG's own `stroke-width="2"` presentation
     * attribute (a CSS declaration always beats a presentation attribute) and
     * is inherited by the two paths. This is the "deemphasized" half: a
     * lighter line, in a softer colour, in a smaller circle.
     */
    box-sizing: border-box;
    width: 32px;
    height: 32px;
    padding: 7px;
    border: 1px solid currentColor;
    border-radius: 50%;
    background-color: #ffffff;
    stroke-width: 1.5;
}

/*
 * The saved bank's display name, above its button. `.cell *` (0,1,0) sets
 * font-size and font-weight on every descendant, so both are restated here.
 * overflow-wrap is the backstop for a long masked account name: it must wrap
 * inside the block, never truncate to nothing and never widen the block past
 * the form (29-UI-SPEC `## UI Considerations`, overflow row).
 *
 * font-weight is 600, not the 500 this shipped with in 29-01. 29-UI-SPEC.md
 * `### Instrument block` gives the instrument name as "16px / 600 / #32325d" and
 * its Typography table reads "600 for labels and instrument names, 500 for
 * prose" - an instrument name is not prose. The 500 was a misread of that row,
 * and 29-UI-REVIEW.md's Typography section repeated it as conforming while its
 * own Priority Fix 1 asked for the card's name to come DOWN to "the 16px/600
 * body role". Both names are 600 so the two saved instruments read as one kind
 * of thing, which is the whole of PAY-02.
 */
.cell .pm-stored-account .pm-account-name {
    text-align: center;
    font-size: 16px;
    font-weight: 600;
    color: #32325d;
    overflow-wrap: anywhere;
}

/*
 * The saved bank's name, once it is the identity half of a ONE-ROW panel. Same
 * decision as the card's name, for the same reason and by the same mechanism:
 * inside `.pm-instrument-row` an instrument's identity is ONE LINE, and an
 * identity too long for its line is clipped with an ellipsis rather than wrapped.
 *
 * This is a deliberate change to the UI-SPEC `overflow` row, which read "must
 * wrap inside the block, never truncate". That rule was written when the name
 * had a block of its own and wrapping cost nothing; in a one-row panel wrapping
 * costs the operator's entire request. The two cannot both hold, and the named
 * test that asserted the old behaviour is re-derived, not deleted - see
 * `a long instrument name is clipped rather than wrapped onto a second row`.
 *
 * It also protects a property PAY-02 depends on. The three panels are asserted
 * to be the SAME HEIGHT; the bank names are the only unbounded strings on the
 * bank rows (an institution name is whatever the bank calls itself), so without
 * this a long one wraps, that panel alone grows past 68px, and the three stop
 * matching. `overflow-wrap: anywhere` above stays as it is: it still governs the
 * same element everywhere outside a one-row panel.
 *
 * (0,4,0) - it has to beat `.cell .pm-stored-account .pm-account-name` at (0,3,0)
 * on class count rather than on source order.
 */
.cell .pm-stored-account .pm-instrument-row .pm-account-name {
    white-space: nowrap;
    overflow: hidden;
    text-overflow: ellipsis;
}

/*
 * Keyboard focus. base.css:36 and base.css:223 both strip the UA focus ring with
 * `outline: none` and nothing replaces it, so today no button on this screen
 * shows keyboard focus at all. :focus-visible matches keyboard and switch input
 * only, so a touch tap looks exactly as it does now. outline-offset is required
 * rather than decorative: .cell button carries border-radius:22px, and a
 * zero-offset outline on a pill renders as a rectangle in some engines.
 */
.cell button:focus-visible, .cell .pm-change-method:focus-visible {
    outline: 2px solid #32325d;
    outline-offset: 2px;
}


/* new card logo layout */
.pm-logo-table {
    width: 100%;
    display: table;
    table-layout: auto;
}

.pm-logo-1, .pm-text-1, .pm-logo-2 {
    display: table-cell;
    vertical-align: middle;
}

.pm-logo-1 {
    width: auto;
    text-align: right;
}

    .pm-logo-1 img {
        max-width: 100%;
        margin-top: 4px;
        margin-right: 16px;
        height: auto;
    }

.pm-text-1 {
    width: 1%;    
    text-align: center;
}

    /*
     * The saved CARD's display name. Same role, and therefore the same type, as
     * the saved BANK's name at `.cell .pm-stored-account .pm-account-name` above:
     * 29-UI-SPEC.md `### Instrument block` gives the instrument name as
     * "16px / 600 / #32325d", and its Typography table assigns 600 to "instrument
     * names". Both blocks now state all three explicitly rather than inheriting,
     * because `.cell *` (0,1,0) sets font-size and font-weight on every descendant.
     *
     * text-decoration:underline is GONE and must not come back. At 18px/600
     * underlined this was the largest, boldest thing under the amount and it read
     * as a link - on the one screen whose entire job is that tapping the right
     * thing is unambiguous - while the control that actually changes the card is
     * the `Change` pill three lines below. It also tied the primary pay button's
     * own label for size, which is the P3 dominance margin.
     *
     * cursor:pointer STAYS. The click binding on .pm-text-1 is live and is kept as
     * a forgiving extra tap target; what is removed is its styling as THE
     * affordance. (29-UI-REVIEW.md Pillar 6, "duplicated on a non-focusable
     * element" - the review keeps the click and objects only to the styling.)
     */
    /*
     * overflow-wrap is the same guarantee `.pm-account-name` already carries: a
     * long masked card name must wrap inside the panel, never truncate to nothing
     * and never widen the block past the form. It matters more now that the name
     * shares its line with the expiry.
     */
    .pm-text-1 .pm-text-content {
        margin-top: 0px !important; /* override from*/
        font-weight: 600;
        font-size: 16px;
        color: #32325d;
        /*line-height: 26px;*/
        cursor: pointer;
        overflow-wrap: anywhere;
    }

.pm-logo-2 {
    width: auto;
    text-align: left;
}
    .pm-logo-2 img {
        max-width: 100%;
        margin-top: 4px;
        margin-left: 16px;
        height: auto;
        visibility: hidden;
    }

.pm-text-1 .pm-expires {
    font-size: 14px;
    color: rgb(105, 115, 134);
}

/*
 * THE EXPIRY ON THE NAME'S LINE - the second half of the operator's request:
 * "also expires on the same line to save vertical space".
 *
 * `.pm-text-content` is a <div> and `.pm-expires` is a <p>; both are block boxes
 * by default, which is what stacked the name and the expiry into two rows.
 * Rendering both inline puts them in ONE line box, and `.pm-text-1`'s existing
 * text-align:center still centres the pair. The expiry stays clearly SECONDARY
 * through size and colour (14px grey against 16px/600 #32325d), which is the
 * distinction that used to be carried by it having a line of its own.
 *
 * SCOPED to `.pm-instrument-row`, which only AccountOrCard.cshtml has. The bare
 * `.pm-text-1 ...` selectors above are shared with Views/Charge/LegacyForms/
 * OldAccountOrCard.cshtml and PlaidTransferUI.cshtml. Nothing renders those two
 * views, but this phase does not own them and a live payment screen is the wrong
 * place to widen a blast radius for tidiness.
 *
 * The separator is drawn here, not written into the DOM, because init.js writes
 * this element's content with innerHTML and must not have to know about it.
 * `:not(:empty)` is the whole point of drawing it in CSS: a stored card with no
 * expiry leaves this element empty, and a separator with nothing after it is the
 * same class of defect as "Pay by undefined" - the patient reads punctuation that
 * promises information the screen does not have.
 */
.cell .pm-instrument-row .pm-text-1 .pm-text-content {
    display: block;
    min-width: 0;
    white-space: nowrap;
    overflow: hidden;
    text-overflow: ellipsis;
}
.cell .pm-instrument-row .pm-text-1 .pm-expires {
    display: block;
    flex: 0 0 auto;
    white-space: nowrap;
}
    .pm-instrument-row .pm-text-1 .pm-expires:not(:empty)::before {
        /*
         * "\00A0\00B7\00A0" - no-break space, middle dot, no-break space, all
         * three written as escapes and NONE of them written as a literal space.
         *
         * In CSS a space TERMINATES a hex escape and is consumed, so the
         * readable-looking `" \00B7 "` renders as " ·" with nothing between the
         * dot and the expiry - which is how this first shipped into the 390px
         * comparison render ("····0000 ·Expires").
         *
         * The LEADING space then had a second, separate failure once the expiry
         * became a block-level flex item rather than an inline box: white space
         * at the start of a line box is collapsed away, so a literal leading
         * space rendered "0000· exp 12/2029" - the dot glued to the name. Both
         * sides are now no-break spaces, which are never collapsed and never
         * line-broken, so the separator is the same three glyphs wherever the
         * expiry sits.
         */
        content: "\00A0\00B7\00A0";
    }

.pm-text-1 .pm-warning-failed {
    font-size: 14px;
    color: rgb(149, 96, 4);
}


/* End of new card logo layout */


.cell .card-container {
    margin: 0 auto;
    padding: 3px;
    width: 100%;
    max-width: 1040px;
    background-color: #fff;
    box-shadow: 0 4px 6px rgba(50, 50, 93, 0.11), 0 1px 3px rgba(0, 0, 0, 0.08);
    border-radius: 4px;
}

.cell .button-container {
    margin: 0 auto;    
    width: 100%;
    max-width: 1040px;
}

    .cell .button-container .button-splitter {
        text-align: center;
        line-height:24px;
        padding-bottom: 4px;
    }    

    .cell .button-container button {
        margin: 10px 0; /* this is custom */
    }

    /*
     * One rhythm for the whole payment list. In the default collapsed state the
     * visible options are: the ACH toggle, the card toggle, Apple Pay, Google
     * Pay and the PayPal toggle. Apple Pay, Google Pay and the PayPal toggle
     * each carry margin-top: 30px, and `.cell .button-container button` gives
     * the two toggles margin: 10px 0 - so 30px here is the only value that
     * makes every consecutive pair 30px apart.
     *
     * The arithmetic, because it is not obvious: the toggle's 10px bottom
     * margin collapses up through `.directdebit-new-account-button` (no border,
     * no padding) into this container's bottom margin, giving 30px; the card
     * block's own top margin collapses down to the 10px on its toggle; adjacent
     * siblings then collapse to max(30, 10) = 30. Raising this back to 40px
     * reinstates the 40px gap the operator flagged. It is also what separates
     * the *expanded* ACH form from the card block, so it has to stay a
     * deliberate-looking gap, not a hairline.
     *
     * THREE containers share this rule since 29-04, not two. The Plaid group was
     * split in that plan: `.button-ach-existing-container` holds the saved
     * instrument and its Change control and stays in section 1;
     * `.button-ach-container` keeps its name, holds only the new-entry submit and
     * moves below the wallet group into section 3. The two Plaid paths are
     * mutually exclusive, so in every office shape exactly ONE of them renders
     * with all its children hidden - a zero-height box carrying this 30px bottom
     * margin. An empty block's own top and bottom margins collapse together and
     * then collapse with its adjacent siblings, so the result is max(...) of the
     * neighbouring margins rather than an extra 30px. That is measured in
     * 29-04-SUMMARY.md rather than assumed.
     */
    .cell .button-ach-container, .cell .button-ach-existing-container, .cell .button-directdebit-container {
        margin-bottom: 30px;
    }

    /*
     * The section-3 container needs a TOP margin as well, and only it does.
     *
     * Measured at 390px in the no-saved-Plaid shape during 29-04: the gap between
     * the wallet group and Plaid's new-entry option came out at 10px, not 30px -
     * the wallet group carries no bottom margin, this container carries no top
     * margin, and the only thing between them was the submit's own 10px from
     * `.cell .button-container button` collapsing up through the container. One
     * option in the list sitting 10px below its predecessor while every other pair
     * sits 30px apart is exactly the uneven rhythm the comment above exists to
     * prevent.
     *
     * The offline rhythm test could not see it: `every consecutive payment option
     * sits the same distance apart` builds a Stripe + Converge fixture with no
     * Plaid container in it at all. The gap was found by measuring both Plaid
     * shapes deliberately, and it is FIXED here rather than absorbed by widening
     * that test's tolerance.
     *
     * 30px on the container, not on its child: in the saved-Plaid shape this
     * container is empty, its own top and bottom margins collapse together to 30,
     * and the distance from the wallet group to the back-home control stays 30 -
     * measured, not assumed.
     */
    .cell .button-ach-container {
        margin-top: 30px;
    }

    /*
     * The two !importants this rule used to carry on background and padding were
     * dropped in phase 29-01. !important outranks specificity entirely, so they
     * beat even the (0,3,1) `.cell .button-container button.pm-change-method`
     * rule and left the Plaid change control a transparent, zero-padding link
     * while the card and Stripe controls rendered as 44px outline pills.
     * The rest of this rule stays: the remaining (0,3,0) declarations are simply
     * outranked by (0,3,1) on the change control, and this rule still styles the
     * class as-is anywhere it is not also .pm-change-method.
     * Note: this selector is also referenced by Views/Charge/LegacyForms/
     * OldAccountOrCard.cshtml:168 and PlaidTransferUI.cshtml:130. Both views are
     * dead - nothing renders them - so this shared-selector edit is harmless, but
     * it is on the record.
     */
    .cell .button-container .ach-new-account-submit-link {
        background: none;
        border: none;
        padding: 0;
        margin: 0 0 20px 0;
        font-weight: 400;
        font-size: 14px;
        line-height: 26px;
        /*input has OS specific font-family*/
        color: #069;
        text-decoration: underline;
        cursor: pointer;
    }

    .cell .button-directdebit-container .pm-failed-method {
        margin-top: 16px;
        text-align: center;

        font-size: 16px;
        color: rgb(149, 96, 4);        
    }

     .cell .button-directdebit-container .pm-another-account {
        margin-top: 26px;
        text-align: center;

        font-size: 16px;
        color: rgb(105, 115, 134);
        text-decoration: underline;
        cursor: pointer;
    }

/*
 * The revealed ACH holder name/email and the submit button that follows them.
 * `.cell .button-container button` only gives the button 10px of top margin,
 * which reads as if the button belongs to the email field. This margin sits on
 * the fields block and collapses with that 10px to 26px of clearance - in line
 * with the `margin-top: 22px` the portal already uses under `.cell .text-block`.
 * Vertical only: no negative horizontal margins here (see the note above
 * `.cell > .text-block`, and tests/e2e/specs/payment-portal.layout.spec.ts).
 */
.cell .directdebit-new-account-button .sach-holder-fields {
    margin-bottom: 26px;
}

.cell button.button-card-black {
    background-color: black;
}

.cell button.button-card-green {
    background-color: #24b47e;
}

/*
 * PAY-03 - the two treatments. Exactly one payment control on the screen wears
 * the primary; every other first-party control wears the secondary. Which one
 * is which is decided by applyActionDominance() in Scripts/charge/all/init.js,
 * never here and never in the markup: these rules only say what the two
 * treatments LOOK like.
 *
 * The two rules above (.button-card-black / .button-card-green) are left in
 * place deliberately - nothing applies them any more, but removing stylesheet
 * rules is not this phase's job.
 *
 * Cascade arithmetic, because a bare class silently does nothing here:
 *
 *   .cell *                       (0,1,0)  base.css:210   font-size, font-weight
 *   .cell input, .cell button     (0,1,1)  base.css:218   color, border-style
 *       (each selector in that list is evaluated on its own, so the button
 *        half is one class plus one type element)
 *   .cell button                  (0,1,1)  base.css:242   width, height,
 *       background-color, border-radius, color, font-size, font-weight
 *
 * `.cell button.pm-btn-primary` is (0,2,1) - one class more than either
 * competitor - and wins outright, including over `border-style: none`. A bare
 * `.pm-btn-primary` would be (0,1,0) and would lose to every one of them.
 *
 * These rules sit AFTER `.cell button.button-card-black` (0,2,1) and
 * `.cell .button-container button` (0,2,1) so that a specificity TIE resolves
 * on source order in favour of the treatment, not against it.
 *
 * `.cell button`'s own 41px height is NOT raised. Doing that would move every
 * button on the screen and disturb two tests in
 * tests/e2e/specs/portal-rhythm.layout.spec.ts - `the sparse intro still does
 * not scroll` (whose freeBelow slack assertions are the real height guard) and
 * `intro buttons fill the card and match each other` (width only). Both titles
 * carry an `at {w}x{h} ({label})` viewport suffix.
 *
 * Why the fill changed. Today's #24b47e carries white text at 2.66:1 and fails
 * both WCAG AA bars; an 18px/600 label does not qualify for the large-text 3:1
 * exemption, which starts at 18.66px bold or 24px normal. #10855c carries white
 * at 4.64:1 and sits on the white card at 4.64:1 too. Both figures are
 * RECOMPUTED from these declared values by `the primary fill and its label meet
 * the contrast bars` in pay-action-area.layout.spec.ts - do not treat the
 * numbers in this comment as the source of truth.
 *
 * HEIGHT IS NO LONGER A DOMINANCE SIGNAL (operator decision, 2026-08-14).
 *
 * This block used to say "dominance rests on three independent signals - fill,
 * height and label size". It rests on TWO now. Having seen the rebuilt screen on
 * a real handset the operator asked for "all the buttons ... the same height
 * like Apple Google PayPal etc", and a primary that is taller than its siblings
 * is that request's direct contradiction. So 48px - already the primary's height,
 * 4px clear of the 44px touch floor, and inside every knob the wallet SDKs expose
 * - became the ONE height every action control on this screen renders at.
 *
 * What replaced it: the primary is the only FILLED control (P1), and it is the
 * only one with an 18px label against everyone else's 16px (P3). Both are still
 * independent, both are still computed rather than declared in the predicate
 * tests, and P2 was re-derived rather than deleted - it now asserts the outline
 * treatment on the siblings AND that the heights are equal, so a silent drift
 * back to a taller primary fails a named test instead of passing quietly.
 *
 * 29-UI-SPEC.md `## Measurable predicates` carries the same withdrawal note.
 */
.cell button.pm-btn-primary {
    display: block;
    width: 100%;
    height: 48px;
    background-color: #10855c;
    border-style: none;
    border-radius: 22px;
    color: #ffffff;
    font-size: 18px;
    font-weight: 600;
}

    /* Mirrors the existing darken-on-press pattern at .cell button:active. */
    .cell button.pm-btn-primary:active {
        background-color: #0c6644;
    }

/*
 * Secondary means lower visual weight - NOT hidden, not shorter, and not below
 * the touch floor. A patient who wants a different method must still see and be
 * able to hit it.
 *
 * 48px, not 44px, since 2026-08-14: same height as the primary, by operator
 * decision (see the withdrawal note above `.cell button.pm-btn-primary`). The
 * weight difference is carried entirely by the outline and the 16px label.
 */
.cell button.pm-btn-secondary {
    display: block;
    width: 100%;
    height: 48px;
    background-color: #ffffff;
    border: 1px solid #6b7c93;
    border-radius: 22px;
    color: #32325d;
    font-size: 16px;
    font-weight: 600;
}

/*
 * BACK HOME - the one button on the pay screen that is not a payment action, and
 * the one the operator could see was short. It sits inside #form-pay at
 * AccountOrCard.cshtml:631 and takes `.cell button`'s 41px, which is both below
 * the 44px touch floor and visibly out of step with everything above it.
 *
 * It is deliberately OUT of the PAY-03 population (the P1 helper in
 * pay-action-area.layout.spec.ts excludes it by id, because it is grey-filled and
 * would otherwise make "exactly one filled action" unsatisfiable). But the
 * operator said "all the buttons", and this one is on the screen, so it is IN the
 * uniform-height population. Nothing about that changes its dominance status: it
 * keeps its #9bacc8 grey fill from :266 and its 18px `.cell button` label.
 *
 * (1,1,1) - the id beats `.cell button` at (0,1,1). Scoped to this id alone:
 * #btn-dispute and #btn-closeconfirm share the grey fill but live on other
 * screens, and `.cell button`'s own 41px is still NOT raised globally - see the
 * portal-rhythm note above `.cell button.pm-btn-primary`.
 */
.cell button#btn-backintro {
    height: 48px;
}

/*
 * WALLET HEIGHTS - one knob per provider, and an honest account of the one that
 * has no knob. Target 48px, matching every first-party control on the screen
 * (operator, 2026-08-14: "all the buttons need to be the same height like Apple
 * Google PayPal etc").
 *
 * APPLE PAY - settable, and 48px is inside Apple's supported band.
 * `<apple-pay-button>` is a real custom element from apple-pay-sdk.js (mounted at
 * AccountOrCard.cshtml:551) and Apple's documented styling surface for it is the
 * `--apple-pay-button-*` custom properties. `--apple-pay-button-height` accepts
 * 30px-64px; Apple's HIG floor is 30px and the element scales its own artwork to
 * the declared height, so 48px is a supported value and NOT a stretch, a scale
 * transform, or a clip. Nothing here distorts the mark.
 *
 *   WHY THREE PROPERTIES AND NOT ONE (2026-08-14, second handset round). The
 *   operator came back with "Apple Pay is too tall now" while the other buttons
 *   read right, and the cause was NOT the height declaration - it was the other
 *   two boxes that height sits inside. apple-pay-sdk.js ships its own shadow-DOM
 *   stylesheet, and its rule for the real button is:
 *
 *       .apple-pay-btn {
 *           box-sizing: var(--apple-pay-button-box-sizing, content-box);
 *           height:     calc(var(--apple-pay-button-height, 30px));
 *           padding:    var(--apple-pay-button-padding, 0);
 *       }
 *
 *   Read that with our old single declaration and the arithmetic is:
 *   CONTENT-BOX + `--apple-pay-button-padding: 5px 0px`, which
 *   Content/css-applepay/checkout-apple-pay.css:22-27 sets on a BARE
 *   `apple-pay-button` selector, so 48 + 5 + 5 = a 58px BUTTON inside a 48px
 *   wrapper (the SDK sizes `.apple-pay-btn-wrapper` from the height property
 *   alone). The element measured 48. The black bar the patient saw was 58 and
 *   overflowed its own wrapper. That is the whole bug: the earlier fix set the
 *   height and never reset the box the height was being added to.
 *
 *   This is NOT a specificity fight and resetting it here is not a workaround for
 *   one. `.cell apple-pay-button` at (0,1,1) already beats the bare
 *   `apple-pay-button` at (0,0,1), and it beats it regardless of source order -
 *   which matters, because _Checkout.cshtml:39 loads checkout-apple-pay.css AFTER
 *   the css-payment bundle. Our height always won. The padding was never
 *   CONTESTED: we simply never declared it, so the other sheet's 5px stood
 *   unopposed. Both properties are declared here now so the button's box is
 *   stated in one place instead of assembled from two stylesheets.
 *
 *   `--apple-pay-button-box-sizing: border-box` is the third, and it is what
 *   makes white-outline land ON 48 rather than near it. The SDK's own
 *   `.apple-pay-btn.white-outline` rule adds `border: 1px solid black`, and under
 *   the SDK's content-box default a border is added OUTSIDE the declared height -
 *   48 + 1 + 1 = 50. border-box folds the border back in, so the rendered
 *   border-box height is exactly 48 whichever style attribute the view carries.
 *   The property is Apple's own (it appears in the SDK stylesheet above), not an
 *   invention of ours, and checkout-apple-pay.css:41 already uses it on the
 *   legacy CSS-only button.
 *
 *   MEASURED, from the SDK stylesheet's arithmetic - the offline fixtures cannot
 *   host Apple's element, so this is box-model arithmetic over Apple's published
 *   rule, not a fixture reading:
 *       before  48px height + 5px + 5px padding, content-box  = 58px button in a 48px wrapper
 *       after   48px height + 0 padding + 1px border, border-box = 48px button in a 48px wrapper
 *   Real confirmation is still Safari on an iPhone against the staging slot.
 *
 * APPLE PAY COLOUR - `buttonstyle="white-outline"` on the element itself, NOT a
 * CSS override. The operator asked for white wallets ("because they are black
 * background Apple Pay and Google Pay dominate the attention on the page"), which
 * is the same complaint 29-UI-REVIEW.md filed: two solid black bars out-weigh the
 * green primary on a screen whose whole purpose is one obvious action.
 *   The supported route is the element's `buttonstyle` attribute. The SDK
 *   validates it against exactly ["black", "white-outline", "white"] and falls
 *   back to "black" on anything else, so this is a first-class API value and not
 *   a colour we are imposing. It is set at AccountOrCard.cshtml:551 rather than
 *   here because the mark itself is not a CSS surface - the SDK swaps the SVG
 *   artwork for the dark-on-light version when the style changes, which no
 *   stylesheet of ours can do.
 *   `white-outline` and NOT `white`: this page's background is white, and Apple's
 *   HIG requires the outlined variant on a light background so the button keeps
 *   an edge. `white` here would be an invisible-edged button and a brand
 *   violation. The SDK draws that edge as `border: 1px solid black` - 21:1
 *   against the white page, far past the 3:1 bar a UI boundary has to clear.
 *
 * GOOGLE PAY - settable for the direct path, best-effort for the Converge path.
 * The office runs one of two integrations, chosen by ConvergeGooglePayMode:
 *   mode 2, the direct path (converge-google-pay-direct.js:68-77) calls
 *     createButton({ ..., buttonSizeMode: 'fill' }). 'fill' means the button
 *     takes the size of ITS CONTAINER, so the container height below IS the
 *     supported API for this path - it is exactly what Google's own docs say to
 *     do with 'fill'.
 *   mode 1, the Converge path (converge-google-pay.js) calls
 *     ConvergeEmbeddedPayment.initGooglePay(btnId, paymentData, callbacks). That
 *     signature takes no style or button-size argument - grepped, not assumed -
 *     so we have no configuration knob for it, only CSS on whatever it renders
 *     into #container-google-pay. Google Pay renders in-document (not an iframe),
 *     so the `.gpay-button` rule below can reach it, but WHAT Converge renders is
 *     NOT VERIFIED from this repo. Mode 1 is therefore best-effort and is the one
 *     wallet whose 48px needs a real-handset check on the staging slot before
 *     anyone claims it.
 *
 * GOOGLE PAY COLOUR - white for mode 2, and BLOCKED for mode 1. Say so plainly.
 *   mode 2 gets `buttonColor: 'white'` passed to createButton()
 *     (converge-google-pay-direct.js). That is Google's own documented option and
 *     it is what makes the wallet stop competing with the green primary. Google's
 *     pay.js draws the white variant with `outline: 1px solid #3C4043` of its own
 *     accord - 10.46:1 against the white page, well past the 3:1 a UI boundary
 *     needs - so the border Google's brand guidelines require on a light
 *     background comes from Google, and nothing here has to add or fake one.
 *   mode 1 CANNOT BE MADE WHITE. `ConvergeEmbeddedPayment.initGooglePay(btnId,
 *     paymentData, callbacks)` takes no styling argument - the same three-argument
 *     shape that blocks PayPal below - so there is no supported route to the
 *     button's colour on that path. It stays black.
 *     NOT FAKED. A CSS `filter: invert()`, a `mix-blend-mode`, or a white overlay
 *     could make it LOOK white, and all three would mangle the Google mark, which
 *     is a brand violation and reads as a broken button. The height rule below is
 *     legitimate because a box size is not the mark; a colour inversion is.
 *     So an office on mode 1 keeps one black wallet. If that matters more than
 *     the integration path does, the fix is to move that office to mode 2, which
 *     is a Converge configuration decision and not a stylesheet one.
 *
 * PAYPAL - NOT SETTABLE, and this is the one that genuinely cannot be pinned.
 * Converge draws PayPal into a CROSS-ORIGIN IFRAME via
 * ConvergeEmbeddedPayment.initPayPalCheckout(btnId, paymentData, callbacks)
 * (converge-paypal.js:44-51). That signature has no style argument, so the
 * PayPal SDK's own `style.height` option (which supports 25-55px, and would
 * happily take 48) is unreachable - we never call the PayPal SDK, Converge does.
 * CSS on #container-paypal-checkout cannot resize content inside a cross-origin
 * iframe, and forcing it with a scale transform or a fixed-height clip would
 * break on the next device, so no height is declared for it.
 *   What the patient actually sees is `.button-paypal-toggle` - OUR button, on
 *   the pm-btn-secondary treatment, so the "Use PayPal" control in the operator's
 *   screenshot IS 48px. Only the provider's own button, revealed after the
 *   toggle is pressed, keeps a height we do not control.
 *
 * ASSERTED FROM SOURCE, NOT FROM A FIXTURE. The offline fixtures cannot host any
 * of these three - they declare their own 45px stand-ins later in the cascade -
 * so `every action button on the pay screen renders at one uniform height` reads
 * these declarations out of base.css rather than measuring a stand-in it wrote
 * itself. See that test for what would actually confirm the wallets.
 */
.cell apple-pay-button {
    --apple-pay-button-height: 48px;
    /* The two that turn a 48px DECLARATION into a 48px RENDERED BLOCK - see the
       box-model arithmetic above. Without them the SDK adds 5px+5px of padding
       from checkout-apple-pay.css:26 and 1px+1px of white-outline border outside
       the height, and the patient gets a 58px bar in a 48px wrapper. */
    --apple-pay-button-padding: 0px 0px;
    --apple-pay-button-box-sizing: border-box;
}

.cell #container-google-pay {
    height: 48px;
}

    /*
     * Google's rendered button, for the mode-1 Converge path where we get no
     * buttonSizeMode. Harmless when absent (mode 2's 'fill' button is sized by
     * the container above, and a selector that matches nothing costs nothing).
     * `background-size: contain` is what keeps the Google mark in proportion
     * inside the taller box instead of cropping it.
     */
    .cell #container-google-pay .gpay-button {
        height: 48px;
        background-size: contain;
    }

.cell .ach-existing-account {
}

.cell .ach-existing-account button {
    margin: 10px 0 0 0;
}

.cell .cancel-container {
    margin: 0 auto;
    width: 100%;
    max-width: 280px;
    margin-top: 20px;
}

.cell .shorter-cancel-container {
    margin: 0 auto;
    width: 100%;
    max-width: 160px;
    margin-top: 20px;
}

.cell .card-only {
    display: block;
}

    .cell .card-only .pm-stored-link {
        font-size: 13px;
        color: #8898aa;
        cursor: pointer;
        text-decoration: underline;
    }

    /*
     * .pm-stored-link is a <button> as of the MR-01 fix, so that the card's "way
     * back" is focusable and Enter/Space-activated like the bank's
     * .pm-use-saved-account already is. This reset is what stops it LOOKING like
     * one: `.cell button` at (0,1,1) would otherwise make it a full-width green
     * 41px pill, which is both wrong in a sentence and - because a filled control
     * inside #form-pay joins the PAY-03 population - a second visible filled
     * action at the moment of payment.
     *
     * (0,3,1) so it beats `.cell button`. The rule above it, at (0,3,0), already
     * beats `.cell button` on class count and keeps owning the link's typography;
     * only the box properties `.cell button` sets and that rule does not are
     * restated here.
     *
     * The focus ring is deliberately NOT reset: `.cell button:focus-visible`
     * gives this control the same 2px ring as every other change control, which
     * is the whole point of making it a button.
     *
     * CSS-01, THE TOUCH TARGET, and the reason the vertical padding is not zero.
     *
     * The first cut of this reset set `padding: 0` alongside `height: auto` at the
     * inherited 13px, which left the hit area one line box - roughly 15-20px tall.
     * This control is the ONLY way back to the saved card once the card-entry
     * fields are open, so a patient on a handset who taps Change by accident could
     * not reliably tap back, and re-keyed a card already on file. That is against
     * the 44px floor this same phase enforces on `.pm-change-method` (:1036),
     * `.pm-btn-secondary` (:1565) and `.pm-btn-primary` (:1543).
     *
     * The target is enlarged by an ABSOLUTE OVERLAY, not by padding and not by a
     * min-height, and the choice is load-bearing rather than stylistic. A
     * `<button>` is an atomic inline-level box: Chrome keeps it participating in
     * the line box by its border box even under `display: inline`, so vertical
     * padding here grows the legend by exactly the padding (measured: +30px) and
     * shifts the whole card block down, invalidating every pinned figure in this
     * phase. `min-height` on an inline-block does the same thing.
     *
     * An absolutely-positioned `::before` is out of flow, so the legend does not
     * move a pixel, and it is part of the button, so a tap anywhere on it
     * activates the button. Same pattern as `.pm-change-method::after` (:1070),
     * which already does this for the three instrument rows - scoped here to the
     * link's own width and expanded vertically only. There is no other
     * interactive element in this legend, so the vertical overlap costs nothing.
     *
     * Measured by `the way back to the saved card is a real touch target` in
     * pay-action-area.layout.spec.ts, which probes the real hit area with
     * elementFromPoint rather than reading a box - the absence of ANY measurement
     * on this control is how an 18px target on a payment screen shipped green.
     */
    .cell .card-only button.pm-stored-link {
        display: inline;
        position: relative;
        width: auto;
        height: auto;
        background: none;
        border: none;
        border-radius: 0;
        padding: 0;
        margin: 0;
        line-height: inherit;
        text-align: inherit;
    }

        .cell .card-only button.pm-stored-link::before {
            content: '';
            position: absolute;
            left: 0;
            right: 0;
            top: 50%;
            height: 48px;
            margin-top: -24px;
        }

/*
 * The wallet group (29-04). Apple Pay, Google Pay and PayPal are provider-drawn
 * and cannot be restyled into our own component, so the WRAPPER and its heading
 * are what give them secondary weight.
 *
 * The 30px is derived from the same rhythm arithmetic as
 * `.cell .button-ach-container` above, not chosen. Before this wrapper existed,
 * `.cell .cell-payment-apple-pay`'s own `margin-top: 30px` produced the gap
 * between the last first-party option and the first wallet. The wrapper now sits
 * between them, so the gap has to be re-established on the wrapper: the group has
 * no top border and no top padding, so its 30px top margin collapses with its
 * first child's (the heading's zero) to 30px, and then collapses with the
 * preceding container's bottom margin - 10px, inherited up from
 * `.cell .button-container button`'s `margin: 10px 0` - to max(30, 10) = 30px.
 * The same value every other consecutive pair carries.
 *
 * The heading's NEGATIVE bottom margin is deliberate and is the only thing that
 * keeps the label attached to the group it labels. Every wallet child carries its
 * own `margin-top: 30px` (Apple Pay, Google Pay and the PayPal toggle each
 * declare it separately), and which of them renders FIRST depends on what the
 * office has enabled - so the gap under the heading cannot be set by styling one
 * named child. Adjacent-sibling collapsing with one negative margin resolves to
 * max(positive) + min(negative) = 30 + (-18) = 12px, whichever wallet is first.
 * Without it the heading would float 30px above the wallets and 30px below the
 * previous option, belonging to neither.
 *
 * `.paypal-collapse-wrap` inside this group stays deliberately unstyled - see the
 * PayPal collapse comment below for why.
 */
.cell .pm-wallet-group {
    margin-top: 30px;
}

/*
 * The Meta typography role from 29-UI-SPEC: 14px / 500 / #32325d. font-size and
 * font-weight are declared EXPLICITLY rather than inherited, because `.cell *`
 * at (0,1,0) sets both on every descendant and beats inheritance.
 */
.cell .pm-wallet-group-heading {
    margin: 0 0 -18px 0;
    font-size: 14px;
    font-weight: 500;
    color: #32325d;
    text-align: center;
}

.cell .cell-paymentRequestHeader {
    margin-top: 46px;
    display: none;
}

.cell .cell-payment-apple-pay {
    margin-top: 30px;
    display: none;
}

.cell #container-apple-pay {
    display: none;
}

.cell .cell-payment-google-pay {
    margin-top: 30px;
    display: none;
}

.cell .cell-payment-paypal {
    margin-top: 30px;
    display: none;
}
    .cell .cell-payment-paypal2 {
        margin-top: 16px;    
    }

    .cell .cell-payment-paypal .container-paypal {
        text-align: center;
    }

/*
 * PayPal collapse (quick task 260810-1cm).
 *
 * The yellow PayPal button over-emphasised PayPal against the black card
 * button, and it cannot be recoloured - Converge renders it inside a
 * cross-origin iframe and none of its wallet entry points takes a style
 * argument. So PayPal hides behind a plain toggle that gets the same
 * button-card-black treatment as the card toggle. Green stays on Bank ACH
 * Debit, which is the option the operator wants emphasised.
 *
 * The toggle carries the 30px itself rather than sitting in a wrapper div: an
 * empty wrapper's top and bottom margins would collapse together once the
 * toggle inside it is hidden, and the gap below Google Pay would move.
 *
 * .paypal-collapse-wrap is intentionally unstyled. Its children keep their own
 * margin-top (30px / 16px), which collapses through the wrapper, so revealing
 * PayPal restores exactly the spacing it had before this change.
 */
.cell button.button-paypal-toggle {
    margin-top: 30px;
}

.cell #card-mount-field {
    padding: 10px;
    margin-bottom: 2px;
}

.cell .confim-message {
    font-size: 16px;
    font-weight: 400;
    line-height: 1.6em;
    color: #32325d;
}

    .cell .confim-message span {
        font-size: inherit;
    }

/*
 *  WORKFLOW
*/

/*
 *  Step 1 - hide forms on load
*/
.cell form.disabled { /* remove disabled clas to show form - unlock in js */
    opacity: 0;
    transform: scale(0.9);
    pointer-events: none;
    display: none;
}

/*
 * Step 2 - Submitting Pay Form Mode: show loading image only - revert if error
*/
.cell.submitting-payment form {
    opacity: 0;
    transform: scale(0.9);
    pointer-events: none;
    display: none;
}

.cell.submitting-payment .success.success-payment {
    pointer-events: all;
    display: block;
}
    .cell.submitting-payment .success.success-payment .icon {
        opacity: 1;
    }

/*
 * Step 3 - Submitted Pay Form Mode: show full success-payment and receipt form
*/
.cell.submitted-payment form#form-pay, .cell.submitted-payment form#form-confirm {
    opacity: 0;
    transform: scale(0.9);
    pointer-events: none;
    display: none;
}

.cell.submitted-payment .success.success-payment {
    pointer-events: all;
    display: block;
}

    .cell.submitted-payment .success.success-payment > * {
        opacity: 1;
        transform: none !important;
    }

    .cell.submitted-payment .success.success-payment > :nth-child(2) {
        transition-delay: 0.1s;
    }

    .cell.submitted-payment .success.success-payment > :nth-child(3) {
        transition-delay: 0.2s;
    }

    .cell.submitted-payment .success.success-payment > :nth-child(4) {
        transition-delay: 0.3s;
    }

    .cell.submitted-payment .success.success-payment .icon .border,
    .cell.submitted-payment .success.success-payment .icon .checkmark {
        opacity: 1;
        stroke-dashoffset: 0 !important;
    }

.cell.submitted-payment form#form-receipt {
    opacity: 1;
    pointer-events: all;
    display: block;
}

/*
 * Step 3 - Submitting Receipt Form
*/
.cell.submitting-receipt form#form-receipt {
    opacity: 0;
    transform: scale(0.9);
    pointer-events: none;
    display: none;
}

.cell.submitting-receipt .success.success-receipt {
    pointer-events: all;
    display: block;
}
    .cell.submitting-receipt .success.success-receipt .icon {
        opacity: 1;
    }


/*
 * Payment Cell - Submitted Receipt Form
*/
.cell.submitted-receipt form#form-receipt {
    opacity: 0;
    transform: scale(0.9);
    pointer-events: none;
    display: none
}

.cell.submitted-receipt .success.success-receipt {
    pointer-events: all;
    display: block;
}
    .cell.submitted-receipt .success.success-receipt > * {
        opacity: 1;
        transform: none !important;
    }
    .cell.submitted-receipt .success.success-receipt > :nth-child(2) {
        transition-delay: 0.1s;
    }
    .cell.submitted-receipt .success.success-receipt > :nth-child(3) {
        transition-delay: 0.2s;
    }
    .cell.submitted-receipt .success.success-receipt > :nth-child(4) {
        transition-delay: 0.3s;
    }
    .cell.submitted-receipt .success.success-receipt .icon .border,
    .cell.submitted-receipt .success.success-receipt .icon .checkmark {
        opacity: 1;
        stroke-dashoffset: 0 !important;
    }

/*.cell.submitted-receipt .success.success-payment {
    opacity: 0;
    pointer-events: none;
    display: none
}*/

/*
 * Payment Cell - Error
*/

.cell .error {
    display: -ms-flexbox;
    display: flex;
    -ms-flex-pack: center;
    justify-content: center;
    position: relative;
    width: 100%;    
    margin-top: 20px;
    padding: 0 15px;
    font-size: 13px;
    opacity: 0;
    transform: translateY(10px);
    transition-property: opacity, transform;
    transition-duration: 0.35s;
    transition-timing-function: cubic-bezier(0.165, 0.84, 0.44, 1);
}

    .cell .error.visible {
        opacity: 1;
        transform: none;
    }

    .cell .error .message {
        font-size: inherit;
        color: #e25950;
    }

    .cell .error svg {
        -ms-flex-negative: 0;
        flex-shrink: 0;
        margin-top: -1px;
        margin-right: 10px;
    }
        .cell .error svg .base {
            fill: #e25950;
        }
        .cell .error svg .glyph {
            fill: #f6f9fc;
        }

/*
 * Payment Cell - Success
*/

.cell .success {
    display: -ms-flexbox;
    display: flex;
    -ms-flex-direction: column;
    flex-direction: column;
    -ms-flex-align: center;
    align-items: center;
    -ms-flex-pack: center;
    justify-content: center;
    position: relative;
    width: 100%;
    top: 0;
    left: 0;
    text-align: center;
    pointer-events: none;    
    display: none;
    padding: 10px;
    padding-bottom: 35px;
}

/*@media (min-width: 670px) {
    .cell .success {
        padding: 40px;
    }
}*/

.cell .success > * {
    transition-property: opacity, transform;
    transition-duration: 0.35s;
    transition-timing-function: cubic-bezier(0.165, 0.84, 0.44, 1);
    opacity: 0;
    transform: translateY(50px);
}

.cell .success .icon {
    margin: 15px 0 30px;
    transform: translateY(70px) scale(0.75);
}
    .cell .success .icon svg {
        will-change: transform;
    }
    .cell .success .icon .border {
        stroke-dasharray: 251;
        stroke-dashoffset: 62.75;
        transform-origin: 50% 50%;
        transition: stroke-dashoffset 0.35s cubic-bezier(0.165, 0.84, 0.44, 1);
        animation: spin 1s linear infinite;
        stroke: #abe9d2;
    }
    .cell .success .icon .checkmark {
        stroke-dasharray: 60;
        stroke-dashoffset: 60;
        transition: stroke-dashoffset 0.35s cubic-bezier(0.165, 0.84, 0.44, 1) 0.35s;
        stroke: #24b47e;
    }

.cell .success .title {
    font-size: 20px;
    font-weight: 500;
    margin-bottom: 8px;
    color: #32325d;
}

.cell .success .message {    
    font-size: 16px;
    font-weight: 400;    
    line-height: 1.6em;
    color: #32325d;
}
    .cell .success .message span {
        font-size: inherit;
    }

.cell .success .reset:active {
    transition-duration: 0.15s;
    transition-delay: 0s;
    opacity: 0.65;
}

.cell .success .reset svg {
    will-change: transform;
}

.cell .success .reset path {
    fill: #d782d9;
}

/* Receipt form */
.cell .row {
    display: -ms-flexbox;
    display: flex;
    margin: 0 0 10px;
}

.cell .field {
    position: relative;
    width: 100%;
}

.cell label {
    width: 100%;
    color: #6b7c93;
    font-size: 16px;
    font-weight: 500;
    overflow: hidden;
    text-overflow: ellipsis;
    white-space: nowrap;
}

.cell .input {
    width: 100%;
    background: transparent;
    padding: 6px 0 8px 0;
    border-bottom: 1px solid #cfd7df;
    transition: border-color 0.3s cubic-bezier(0.165, 0.84, 0.44, 1);
    font-size: 16px;
    font-weight: 500;
    color: #6b7c93;
}
    .cell .input.receipt-input, .cell .input.general-input {
        border: 1px solid #cfd7df;
        padding: 6px 6px 8px 6px;
        color: #32325d;
        border-radius: 4px;
    }

    .cell .input.general-input {
        background: #f6f6f6;
        font-weight: 400;
        margin-top: 10px;
    }

        .cell .div-direct .input.general-input {
            margin-top: 2px;
        }

        .cell .input.general-input.plan-input {        
            margin-top: 0px;
            text-align: center;
            font-size: 18px;
        }

    .cell .input::-webkit-input-placeholder {
        color: #9bacc8;
    }

    .cell .input::-moz-placeholder {
        color: #9bacc8;
    }

    .cell .input:-ms-input-placeholder {
        color: #9bacc8;
    }

    .cell .input:focus {
        border-color: #6b7c93;
    }

.msg-valid {
    margin-top:12px;
    display: block;    
    text-align: center;
    color: red;
}

.msg-star {
    color: red;
}

.div-goodnews {
    display: block;
    margin: 16px auto;
    font-weight: 500;
    font-size: 16px;
    line-height: 22px;
    color: #468847;
    background-color: #dff0d8;    
    padding: 15px;  
    border: 1px solid #d6e9c6;
    border-radius: 4px;
}

.div-badnews {
    display: block;
    margin: 16px auto;
    font-weight: 500;
    font-size: 16px;
    line-height: 22px;
    border: 1px solid #fbeed5;
    border-radius: 4px;
    color: #c09853;
    padding: 15px;
    background-color: #fcf8e3;
}

/* Safari no height fix*/
input[type="date"] {
    height: 2.375rem;
}
.cell .text-block .dpui-numberPicker {
    display: block;
}
    .cell .text-block .dpui-numberPicker button {
        display: inline-block;
        margin: 0;
        border: 1px solid #dddddd;
        font-size: 26px;
        line-height: 36px;
        width: 40px;
        height: 42px;
        outline: none;
        cursor: pointer;
        border-radius: 5px;
        background: #f0f0f0;
        background: -moz-linear-gradient(top, #f0f0f0 0%, #cccccc 100%);
        background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#f0f0f0), color-stop(100%,#cccccc));
        background: -webkit-linear-gradient(top, #f0f0f0 0%,#cccccc 100%);
        background: -o-linear-gradient(top, #f0f0f0 0%,#cccccc 100%);
        background: -ms-linear-gradient(top, #f0f0f0 0%,#cccccc 100%);
        background: linear-gradient(to bottom, #f0f0f0 0%,#cccccc 100%);
        filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#f0f0f0', endColorstr='#cccccc',GradientType=0 );
    }
        .cell .text-block .dpui-numberPicker button:first-of-type {
            margin: 0;
        }

        .cell .text-block .dpui-numberPicker button:hover {
            background: #cccccc;
            background: -moz-linear-gradient(top, #cccccc 0%, #f0f0f0 100%);
            background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#cccccc), color-stop(100%,#f0f0f0));
            background: -webkit-linear-gradient(top, #cccccc 0%,#f0f0f0 100%);
            background: -o-linear-gradient(top, #cccccc 0%,#f0f0f0 100%);
            background: -ms-linear-gradient(top, #cccccc 0%,#f0f0f0 100%);
            background: linear-gradient(to bottom, #cccccc 0%,#f0f0f0 100%);
            filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#cccccc', endColorstr='#f0f0f0',GradientType=0 );
        }

.cell .text-block .dpui-numberPicker-input {
    display: inline-block;
    color: black;
    width: 230px;
    height: 42px;
    line-height: 36px;
    padding: 0 8px;
    margin: 0;
    text-align: center;
    outline: none;
    vertical-align: top;
    border: 0;
    background: #f6f9fc;
    font-weight: 600;
    font-size: 22px;
}

.cell .text-block .dpui-numberPicker.dpui-numberPicker-min .dpui-numberPicker-decrease, .cell .text-block .dpui-numberPicker.dpui-numberPicker-max .dpui-numberPicker-increase {
    background: #cccccc;
    color: #999999;
}